All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Capella <sebastian.capella@linaro.org>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Russell King <linux@arm.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Robin Holt <holt@sgi.com>, Thomas Gleixner <tglx@linutronix.de>,
	Konstantin Khlebnikov <k.khlebnikov@samsung.com>,
	Steven Capper <steve.capper@linaro.org>,
	Stephen Warren <swarren@nvidia.com>, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH v9 1/2] ARM: avoid tracers in soft_restart
Date: Mon, 14 Apr 2014 15:37:58 -0700	[thread overview]
Message-ID: <CADHgK6vY4tzb3fJRZyTDZ=e7e9sEhDDc5_ja28qna-AhXwaFEA@mail.gmail.com> (raw)
In-Reply-To: <20140414105314.GB3530@arm.com>

Hi Will,

On 14 April 2014 03:53, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Mar 18, 2014 at 09:40:57PM +0000, Sebastian Capella wrote:
>> Use of tracers in local_irq_disable is causes abort loops when called
>> with irqs disabled using a temporary stack.  Replace local_irq_disable
>> with raw_local_irq_disable instead to avoid tracers.
>
> Do you have any more information about these aborts? At the time we call
> local_irq_disable, the stack is still intact, so if the issue is simply
> related to having any tracers active at the call_with_stack invocation, we'd
> be better off disabling tracing here altogether.

This is specifically for when soft_restart is called in the
hibernation path with tracers enabled.  At that point, we've already
switched to a temporary stack, and when we call local_irq_disable,
we'll see this:

In the local_irq_disable, it ends up calling trace_hardirqs_off
(CONFIG_TRACE_IRQFLAGS_SUPPORT is enabled), which calls
trace_hardirqs_off_caller which checks lockdep_recursion in the
current task, but we've switched to a temporary stack with the
call_with_stack, and get_current is returning NULL.  This
triggers a data abort, which calls trace_hardirqs_off
again and so on.

We originally had a patch which added a soft restart called
soft_restart_noirq which avoided the irq disable.

You can see the discussion here:
https://patchwork.kernel.org/patch/3677591/

Thanks!

Sebastian

WARNING: multiple messages have this Message-ID (diff)
From: sebastian.capella@linaro.org (Sebastian Capella)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 1/2] ARM: avoid tracers in soft_restart
Date: Mon, 14 Apr 2014 15:37:58 -0700	[thread overview]
Message-ID: <CADHgK6vY4tzb3fJRZyTDZ=e7e9sEhDDc5_ja28qna-AhXwaFEA@mail.gmail.com> (raw)
In-Reply-To: <20140414105314.GB3530@arm.com>

Hi Will,

On 14 April 2014 03:53, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Mar 18, 2014 at 09:40:57PM +0000, Sebastian Capella wrote:
>> Use of tracers in local_irq_disable is causes abort loops when called
>> with irqs disabled using a temporary stack.  Replace local_irq_disable
>> with raw_local_irq_disable instead to avoid tracers.
>
> Do you have any more information about these aborts? At the time we call
> local_irq_disable, the stack is still intact, so if the issue is simply
> related to having any tracers active at the call_with_stack invocation, we'd
> be better off disabling tracing here altogether.

This is specifically for when soft_restart is called in the
hibernation path with tracers enabled.  At that point, we've already
switched to a temporary stack, and when we call local_irq_disable,
we'll see this:

In the local_irq_disable, it ends up calling trace_hardirqs_off
(CONFIG_TRACE_IRQFLAGS_SUPPORT is enabled), which calls
trace_hardirqs_off_caller which checks lockdep_recursion in the
current task, but we've switched to a temporary stack with the
call_with_stack, and get_current is returning NULL.  This
triggers a data abort, which calls trace_hardirqs_off
again and so on.

We originally had a patch which added a soft restart called
soft_restart_noirq which avoided the irq disable.

You can see the discussion here:
https://patchwork.kernel.org/patch/3677591/

Thanks!

Sebastian

  reply	other threads:[~2014-04-14 22:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 21:40 [PATCH v9 0/2] hibernation support on ARM Sebastian Capella
2014-03-18 21:40 ` Sebastian Capella
2014-03-18 21:40 ` [PATCH v9 1/2] ARM: avoid tracers in soft_restart Sebastian Capella
2014-03-18 21:40   ` Sebastian Capella
2014-04-14 10:53   ` Will Deacon
2014-04-14 10:53     ` Will Deacon
2014-04-14 10:53     ` Will Deacon
2014-04-14 22:37     ` Sebastian Capella [this message]
2014-04-14 22:37       ` Sebastian Capella
2014-04-14 22:37       ` Sebastian Capella
2014-03-18 21:40 ` [PATCH v9 2/2] ARM hibernation / suspend-to-disk Sebastian Capella
2014-03-18 21:40   ` Sebastian Capella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADHgK6vY4tzb3fJRZyTDZ=e7e9sEhDDc5_ja28qna-AhXwaFEA@mail.gmail.com' \
    --to=sebastian.capella@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=holt@sgi.com \
    --cc=k.khlebnikov@samsung.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=steve.capper@linaro.org \
    --cc=swarren@nvidia.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.