From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from devils.ext.ti.com ([198.47.26.153]:60731 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751654AbbJSOPq (ORCPT ); Mon, 19 Oct 2015 10:15:46 -0400 Message-ID: <5624FB12.80709@ti.com> Date: Mon, 19 Oct 2015 10:15:46 -0400 From: Murali Karicheri MIME-Version: 1.0 To: Russell King - ARM Linux , Greg KH CC: Subject: Re: request to merge commit 3302caddf10ad50710dbb7a94ccbdb3ad5bf1412 References: <560080ED.6090607@ti.com> <20151017213257.GA11319@kroah.com> <20151017224018.GS32532@n2100.arm.linux.org.uk> In-Reply-To: <20151017224018.GS32532@n2100.arm.linux.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: 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 >>> 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 >>> Signed-off-by: Russell King >>> ================================================================================ >>> >>> 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