From: Russ Dill <Russ.Dill@ti.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linaro-kernel@lists.linaro.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-pm@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org,
Sebastian Capella <sebastian.capella@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org, Robin Holt <holt@sgi.com>
Subject: Re: [PATCH RFC v1 1/3] ARM: Add irq disabled version of soft_restart.
Date: Tue, 25 Feb 2014 09:15:33 -0800 [thread overview]
Message-ID: <530CCFB5.5030205@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402251125500.21251@ionos.tec.linutronix.de>
On 02/25/2014 02:27 AM, Thomas Gleixner wrote:
> On Mon, 24 Feb 2014, Russ Dill wrote:
>> On 02/24/2014 03:13 PM, Sebastian Capella wrote:
>>> Quoting Russell King - ARM Linux (2014-02-22 02:26:17)
>>>> On Tue, Feb 18, 2014 at 05:52:07PM -0800, Sebastian Capella
>>>> wrote:
>>>>> From: Russ Dill <Russ.Dill@ti.com>
>>>>>
>>>>> This adds the ability to run soft_restart with
>>>>> local_irq/fiq_disable already called. This is helpful for
>>>>> the hibernation code paths.
>>>>
>>>> I'd rather keep this simple. There's no problem with calling
>>>> soft_restart with interrupts already disabled.
>>>> local_irq_disable()/local_fiq_disable() there should be
>>>> harmless.
>>>
>>> Hi Russell,
>>>
>>> I'm observing a data abort loop when I replace this call:
>>>
>>> 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.
>>>
>>> Do you have any suggestions here?
>>>
>>> Thanks,
>>>
>>> Sebastian
>>>
>>
>> So the alternative is to have a version of the call that calls a
>> special no trace version of
>> local_irq_disable()/local_fiq_disable(). Which would be
>> preferable? Having a noirq version of soft_restart seems much
>> simpler to me.
>
> If you want escape the tracer and in that case you really want it
> being on a different stack, use raw_local_irq_* which are not
> traced.
So it might make sense to change soft_restart to use the
raw_local_irq_* calls.
WARNING: multiple messages have this Message-ID (diff)
From: Russ.Dill@ti.com (Russ Dill)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v1 1/3] ARM: Add irq disabled version of soft_restart.
Date: Tue, 25 Feb 2014 09:15:33 -0800 [thread overview]
Message-ID: <530CCFB5.5030205@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402251125500.21251@ionos.tec.linutronix.de>
On 02/25/2014 02:27 AM, Thomas Gleixner wrote:
> On Mon, 24 Feb 2014, Russ Dill wrote:
>> On 02/24/2014 03:13 PM, Sebastian Capella wrote:
>>> Quoting Russell King - ARM Linux (2014-02-22 02:26:17)
>>>> On Tue, Feb 18, 2014 at 05:52:07PM -0800, Sebastian Capella
>>>> wrote:
>>>>> From: Russ Dill <Russ.Dill@ti.com>
>>>>>
>>>>> This adds the ability to run soft_restart with
>>>>> local_irq/fiq_disable already called. This is helpful for
>>>>> the hibernation code paths.
>>>>
>>>> I'd rather keep this simple. There's no problem with calling
>>>> soft_restart with interrupts already disabled.
>>>> local_irq_disable()/local_fiq_disable() there should be
>>>> harmless.
>>>
>>> Hi Russell,
>>>
>>> I'm observing a data abort loop when I replace this call:
>>>
>>> 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.
>>>
>>> Do you have any suggestions here?
>>>
>>> Thanks,
>>>
>>> Sebastian
>>>
>>
>> So the alternative is to have a version of the call that calls a
>> special no trace version of
>> local_irq_disable()/local_fiq_disable(). Which would be
>> preferable? Having a noirq version of soft_restart seems much
>> simpler to me.
>
> If you want escape the tracer and in that case you really want it
> being on a different stack, use raw_local_irq_* which are not
> traced.
So it might make sense to change soft_restart to use the
raw_local_irq_* calls.
WARNING: multiple messages have this Message-ID (diff)
From: Russ Dill <Russ.Dill@ti.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Capella <sebastian.capella@linaro.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
<linux-kernel@vger.kernel.org>, <linux-pm@vger.kernel.org>,
<linaro-kernel@lists.linaro.org>,
<linux-arm-kernel@lists.infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will.deacon@arm.com>, Robin Holt <holt@sgi.com>
Subject: Re: [PATCH RFC v1 1/3] ARM: Add irq disabled version of soft_restart.
Date: Tue, 25 Feb 2014 09:15:33 -0800 [thread overview]
Message-ID: <530CCFB5.5030205@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402251125500.21251@ionos.tec.linutronix.de>
On 02/25/2014 02:27 AM, Thomas Gleixner wrote:
> On Mon, 24 Feb 2014, Russ Dill wrote:
>> On 02/24/2014 03:13 PM, Sebastian Capella wrote:
>>> Quoting Russell King - ARM Linux (2014-02-22 02:26:17)
>>>> On Tue, Feb 18, 2014 at 05:52:07PM -0800, Sebastian Capella
>>>> wrote:
>>>>> From: Russ Dill <Russ.Dill@ti.com>
>>>>>
>>>>> This adds the ability to run soft_restart with
>>>>> local_irq/fiq_disable already called. This is helpful for
>>>>> the hibernation code paths.
>>>>
>>>> I'd rather keep this simple. There's no problem with calling
>>>> soft_restart with interrupts already disabled.
>>>> local_irq_disable()/local_fiq_disable() there should be
>>>> harmless.
>>>
>>> Hi Russell,
>>>
>>> I'm observing a data abort loop when I replace this call:
>>>
>>> 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.
>>>
>>> Do you have any suggestions here?
>>>
>>> Thanks,
>>>
>>> Sebastian
>>>
>>
>> So the alternative is to have a version of the call that calls a
>> special no trace version of
>> local_irq_disable()/local_fiq_disable(). Which would be
>> preferable? Having a noirq version of soft_restart seems much
>> simpler to me.
>
> If you want escape the tracer and in that case you really want it
> being on a different stack, use raw_local_irq_* which are not
> traced.
So it might make sense to change soft_restart to use the
raw_local_irq_* calls.
next prev parent reply other threads:[~2014-02-25 17:15 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-19 1:52 [PATCH RFC v1 0/3] hibernation support on ARM Sebastian Capella
2014-02-19 1:52 ` Sebastian Capella
2014-02-19 1:52 ` [PATCH RFC v1 1/3] ARM: Add irq disabled version of soft_restart Sebastian Capella
2014-02-19 1:52 ` Sebastian Capella
2014-02-22 10:26 ` Russell King - ARM Linux
2014-02-22 10:26 ` Russell King - ARM Linux
2014-02-24 23:13 ` Sebastian Capella
2014-02-24 23:13 ` Sebastian Capella
2014-02-25 0:22 ` Sebastian Capella
2014-02-25 0:22 ` Sebastian Capella
2014-02-25 7:56 ` Russ Dill
2014-02-25 7:56 ` Russ Dill
2014-02-25 7:56 ` Russ Dill
2014-02-25 10:27 ` Thomas Gleixner
2014-02-25 10:27 ` Thomas Gleixner
2014-02-25 17:15 ` Russ Dill [this message]
2014-02-25 17:15 ` Russ Dill
2014-02-25 17:15 ` Russ Dill
2014-02-25 23:24 ` Sebastian Capella
2014-02-25 23:24 ` Sebastian Capella
2014-02-19 1:52 ` [PATCH RFC v1 2/3] Fix hibernation restore hang in freeze_processes Sebastian Capella
2014-02-19 1:52 ` Sebastian Capella
2014-02-24 7:09 ` Ming Lei
2014-02-24 7:09 ` Ming Lei
2014-02-19 1:52 ` [PATCH RFC v1 3/3] ARM hibernation / suspend-to-disk Sebastian Capella
2014-02-19 1:52 ` Sebastian Capella
2014-02-19 16:12 ` Lorenzo Pieralisi
2014-02-19 16:12 ` Lorenzo Pieralisi
2014-02-19 19:10 ` Russ Dill
2014-02-19 19:10 ` Russ Dill
2014-02-19 19:10 ` Russ Dill
2014-02-20 10:37 ` Lorenzo Pieralisi
2014-02-20 10:37 ` Lorenzo Pieralisi
2014-02-19 19:33 ` Sebastian Capella
2014-02-19 19:33 ` Sebastian Capella
2014-02-20 16:27 ` Lorenzo Pieralisi
2014-02-20 16:27 ` Lorenzo Pieralisi
2014-02-21 18:39 ` Sebastian Capella
2014-02-21 18:39 ` Sebastian Capella
2014-02-21 23:59 ` Sebastian Capella
2014-02-21 23:59 ` Sebastian Capella
2014-02-22 4:37 ` Sebastian Capella
2014-02-22 4:37 ` Sebastian Capella
2014-02-22 6:46 ` Russ Dill
2014-02-22 6:46 ` Russ Dill
2014-02-22 6:46 ` Russ Dill
2014-02-22 10:22 ` Russell King - ARM Linux
2014-02-22 10:22 ` Russell King - ARM Linux
2014-02-22 10:16 ` Russell King - ARM Linux
2014-02-22 10:16 ` Russell King - ARM Linux
2014-02-22 12:13 ` Lorenzo Pieralisi
2014-02-22 12:13 ` Lorenzo Pieralisi
2014-02-22 22:30 ` Pavel Machek
2014-02-22 22:30 ` Pavel Machek
2014-02-21 1:01 ` Sebastian Capella
2014-02-21 1:01 ` Sebastian Capella
2014-02-22 10:38 ` Russell King - ARM Linux
2014-02-22 10:38 ` Russell King - ARM Linux
2014-02-22 12:09 ` Lorenzo Pieralisi
2014-02-22 12:09 ` Lorenzo Pieralisi
2014-02-22 22:28 ` Pavel Machek
2014-02-22 22:28 ` Pavel Machek
2014-02-23 19:52 ` Sebastian Capella
2014-02-23 19:52 ` Sebastian Capella
2014-02-23 20:02 ` Sebastian Capella
2014-02-23 20:02 ` Sebastian Capella
2014-02-25 11:32 ` Lorenzo Pieralisi
2014-02-25 11:32 ` Lorenzo Pieralisi
2014-02-25 17:55 ` Sebastian Capella
2014-02-25 17:55 ` Sebastian Capella
2014-02-26 10:24 ` Lorenzo Pieralisi
2014-02-26 10:24 ` Lorenzo Pieralisi
2014-02-26 17:50 ` Sebastian Capella
2014-02-26 17:50 ` Sebastian Capella
2014-02-26 19:03 ` Lorenzo Pieralisi
2014-02-26 19:03 ` Lorenzo Pieralisi
2014-02-26 19:03 ` Lorenzo Pieralisi
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=530CCFB5.5030205@ti.com \
--to=russ.dill@ti.com \
--cc=akpm@linux-foundation.org \
--cc=holt@sgi.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=sebastian.capella@linaro.org \
--cc=tglx@linutronix.de \
--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.