All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Dill <Russ.Dill@ti.com>
To: Sebastian Capella <sebastian.capella@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@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>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Nicolas Pitre <nico@linaro.org>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Jonathan Austin <Jonathan.Austin@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
	Stephen Boyd <sboyd@codeaurora.org>
Subject: Re: [PATCH RFC v1 3/3] ARM hibernation / suspend-to-disk
Date: Fri, 21 Feb 2014 22:46:59 -0800	[thread overview]
Message-ID: <530847E3.4070401@ti.com> (raw)
In-Reply-To: <20140222043714.19852.67450@capellas-linux>

On 02/21/2014 08:37 PM, Sebastian Capella wrote:
> Quoting Sebastian Capella (2014-02-21 15:59:11)
>> - Cyril Chemparathy as his email is bouncing back to me. 
>>
>> Quoting Sebastian Capella (2014-02-21 10:39:56)
>>> Quoting Lorenzo Pieralisi (2014-02-20 08:27:55)
>>>>>>> +     cpu_switch_mm(idmap_pgd, &init_mm);
>>   [ ... ]
>>> I can try removing it and seeing if there are side effects.
>>
>> FYI, It's definitely hanging with this removed, still looking.
> 
> I see when we reach this call, the 1st level page table @ TTBR0 is located
> at different memory locations each run (expected).  If we omit the
> cpu_switch_mm we're corrupting the page table causing the observed
> intermittent failures.  I believe these match the corruption you expected.
> 
> The reason this doesn't happen when I leave the call is that idmap_pgd
> is always at the same memory location.  I expect this is because it's
> allocated during init.  I've seen the same address 50/50 times for
> idmap_pgd.  I don't think it is correct to rely on this behavior.
> 
> Would it be appropriate to use the swapper_pg_dir directly in place
> of idmap_pgd?
>   - I do not see any modification to the swapper_pg_dir contents in the
>     code that would change from init time.
>   - swapper_pg_dir is always at the same offset.
> 
> Ideally we should have no issue with overwriting it with identical data.
> 
> I've run a couple hundred test loops using swapper_pg_dir and so far
> there are no failures.

If there is worry about this, you could setup a page mapping in a
__nosave region, preventing it from being overwritten.


WARNING: multiple messages have this Message-ID (diff)
From: Russ Dill <Russ.Dill@ti.com>
To: Sebastian Capella <sebastian.capella@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Len Brown <len.brown@intel.com>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	Jonathan Austin <Jonathan.Austin@arm.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Will Deacon <Will.Deacon@arm.com>,
	Nicolas Pitre <nico@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Pavel Machek <pavel@ucw.cz>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
	Stephen Boyd <sboyd@codeaurora.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH RFC v1 3/3] ARM hibernation / suspend-to-disk
Date: Fri, 21 Feb 2014 22:46:59 -0800	[thread overview]
Message-ID: <530847E3.4070401@ti.com> (raw)
In-Reply-To: <20140222043714.19852.67450@capellas-linux>

On 02/21/2014 08:37 PM, Sebastian Capella wrote:
> Quoting Sebastian Capella (2014-02-21 15:59:11)
>> - Cyril Chemparathy as his email is bouncing back to me. 
>>
>> Quoting Sebastian Capella (2014-02-21 10:39:56)
>>> Quoting Lorenzo Pieralisi (2014-02-20 08:27:55)
>>>>>>> +     cpu_switch_mm(idmap_pgd, &init_mm);
>>   [ ... ]
>>> I can try removing it and seeing if there are side effects.
>>
>> FYI, It's definitely hanging with this removed, still looking.
> 
> I see when we reach this call, the 1st level page table @ TTBR0 is located
> at different memory locations each run (expected).  If we omit the
> cpu_switch_mm we're corrupting the page table causing the observed
> intermittent failures.  I believe these match the corruption you expected.
> 
> The reason this doesn't happen when I leave the call is that idmap_pgd
> is always at the same memory location.  I expect this is because it's
> allocated during init.  I've seen the same address 50/50 times for
> idmap_pgd.  I don't think it is correct to rely on this behavior.
> 
> Would it be appropriate to use the swapper_pg_dir directly in place
> of idmap_pgd?
>   - I do not see any modification to the swapper_pg_dir contents in the
>     code that would change from init time.
>   - swapper_pg_dir is always at the same offset.
> 
> Ideally we should have no issue with overwriting it with identical data.
> 
> I've run a couple hundred test loops using swapper_pg_dir and so far
> there are no failures.

If there is worry about this, you could setup a page mapping in a
__nosave region, preventing it from being overwritten.

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 3/3] ARM hibernation / suspend-to-disk
Date: Fri, 21 Feb 2014 22:46:59 -0800	[thread overview]
Message-ID: <530847E3.4070401@ti.com> (raw)
In-Reply-To: <20140222043714.19852.67450@capellas-linux>

On 02/21/2014 08:37 PM, Sebastian Capella wrote:
> Quoting Sebastian Capella (2014-02-21 15:59:11)
>> - Cyril Chemparathy as his email is bouncing back to me. 
>>
>> Quoting Sebastian Capella (2014-02-21 10:39:56)
>>> Quoting Lorenzo Pieralisi (2014-02-20 08:27:55)
>>>>>>> +     cpu_switch_mm(idmap_pgd, &init_mm);
>>   [ ... ]
>>> I can try removing it and seeing if there are side effects.
>>
>> FYI, It's definitely hanging with this removed, still looking.
> 
> I see when we reach this call, the 1st level page table @ TTBR0 is located
> at different memory locations each run (expected).  If we omit the
> cpu_switch_mm we're corrupting the page table causing the observed
> intermittent failures.  I believe these match the corruption you expected.
> 
> The reason this doesn't happen when I leave the call is that idmap_pgd
> is always at the same memory location.  I expect this is because it's
> allocated during init.  I've seen the same address 50/50 times for
> idmap_pgd.  I don't think it is correct to rely on this behavior.
> 
> Would it be appropriate to use the swapper_pg_dir directly in place
> of idmap_pgd?
>   - I do not see any modification to the swapper_pg_dir contents in the
>     code that would change from init time.
>   - swapper_pg_dir is always at the same offset.
> 
> Ideally we should have no issue with overwriting it with identical data.
> 
> I've run a couple hundred test loops using swapper_pg_dir and so far
> there are no failures.

If there is worry about this, you could setup a page mapping in a
__nosave region, preventing it from being overwritten.

  reply	other threads:[~2014-02-22  6:48 UTC|newest]

Thread overview: 91+ 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
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 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-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-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 [this message]
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: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 10:16           ` Russell King - ARM Linux
2014-02-22 12:13           ` Lorenzo Pieralisi
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-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 10:38       ` Russell King - ARM Linux
2014-02-22 12:09       ` Lorenzo Pieralisi
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-22 22:28           ` Pavel Machek
2014-02-23 19:52         ` Sebastian Capella
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-23 20:02           ` Sebastian Capella
2014-02-25 11:32           ` Lorenzo Pieralisi
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 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=530847E3.4070401@ti.com \
    --to=russ.dill@ti.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Jonathan.Austin@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=len.brown@intel.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=lorenzo.pieralisi@arm.com \
    --cc=nico@linaro.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=santosh.shilimkar@ti.com \
    --cc=sboyd@codeaurora.org \
    --cc=sebastian.capella@linaro.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.