Hello Mark, On Thu, Mar 19, 2015 at 11:24:30AM +0000, Mark Brown wrote: > On Wed, Mar 18, 2015 at 03:48:54PM +0100, Uwe Kleine-König wrote: > > On Wed, Mar 18, 2015 at 01:58:54PM +0000, Mark Brown wrote: > > > > My point here is that the analysis of the issue shouldn't depend on > > > spidev in particular, if you need to call out the specific driver you're > > > working with that's an alarm sign that it's doing something weird and > > > perhaps the problem is with the driver. > > > This just happens to be the driver I saw the problem with. Don't have > > another spi device on that bus to cross check with other drivers. I > > wouldn't be too concerned here. > > Sure, but it's better to write it up in terms of a generic driver - it's > the difference between "let's work around this driver" and "the core > isn't doing the right thing for drivers here". OK, so something like: ------------>8------------ spi: trigger trace event for message-done before mesg->complete The message's complete callback might (permissibly) free the memory that holds the message. As recording the trace event for the end of a transfer accesses this message the recording is better done first. This fixes an oops observed on a 3.14-rt system with bus activity using spidev after echo 1 > /sys/kernel/debug/tracing/events/spi/enable . (For spidev mesg->complete points to spidev_complete. Calling that unblocks spidev_sync and so spidev_sync_write (or spidev_sync_read). This in turn leaves the scope of the local variable that holds the message.) ------------>8------------ Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html