On 10/17/2015 06:40 PM, Russell King - ARM Linux wrote:
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?
I had a kernel with most of the debug options enabled and got this. Will
reproduce and send you the .config at the next available opportunity.
--
Murali Karicheri
Linux Kernel, Keystone
--
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