On Sat, Oct 17, 2015 at 02:32:57PM -0700, Greg KH wrote: > On Mon, Sep 21, 2015 at 06:13:01PM -0400, Murali Karicheri wrote: > > Hi Maintainer, > > > > The below commit fixes the Warning shown in the trace below when debug > > options are enabled in the kernel build. Could you please merge this to > > address the issue for v4.1.9? > > > > Thanks > > ============================================================================ > > commit 3302caddf10ad50710dbb7a94ccbdb3ad5bf1412 > > Author: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > Date: Thu Aug 20 16:13:37 2015 +0100 > > > > ARM: entry: efficiency cleanups > > > > Make the "fast" syscall return path fast again. The addition of IRQ > > tracing and context tracking has made this path grossly inefficient. > > We can do much better if these options are enabled if we save the > > syscall return code on the stack - we then don't need to save a bunch > > of registers around every single callout to C code. > > > > Acked-by: Will Deacon <will.deacon@xxxxxxx> > > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > ================================================================================ > > > > Warning log below which is addressed by above commit. > > How does the above git commit id, solve the warning you show here: I can't fathom this one out either this evening. However, I know the old code had _some_ issue wrt syscall tracing and the IRQ state which this did fix as a side effect, but I don't think this IRQ trace splat was it. All the paths I can see should not cause this. There are three possible paths to work_pending, and thus on to do_work_pending(): 1. via ret_fast_syscall, which always disables interrupts and notifies that they've been disabled. 2. via ret_slow_syscall/ret_to_user, which also does the irq disable and notify thing. 3. ret_to_user_from_irq, which is called from the IRQ path where we're certain that IRQs have been disabled and been notified as such. The last seen IRQ events show that we followed a path of ret_slow_syscall, where IRQs were disabled, proceeded through (possibly doing some work in the process) to no_work_pending, where we notified the impending IRQ enable. From that point, the only way is to drop into userspace. All routes subsequently back out of userspace, with the exception of FIQs, notifies the IRQ tracing stuff that IRQs are disabled on re-entry to kernel space, which will have the effect of generating another IRQ-event. However, we see that the last IRQ event was the IRQ enable in no_work_pending. So, the mistery is how we got from no_work_pending back into do_work_pending. If we did, then that shows some other bug - one which is possibly masked by this change. Or, I'm missing something this evening. Murali, can you explain under what circumstances you see this warning please? -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html