Re: request to merge commit 3302caddf10ad50710dbb7a94ccbdb3ad5bf1412

[Murali Karicheri <m-karicheri2@ti.com>]

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@arm.linux.org.uk>
>>> 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@arm.com>
>>>      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>> ================================================================================
>>>
>>> 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