linux-kernel - Re: [PATCH RFC v1 3/3] ARM hibernation / suspend-to-disk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <530847E3.4070401@ti.com>
Date:	Fri, 21 Feb 2014 22:46:59 -0800
From:	Russ Dill <Russ.Dill@...com>
To:	Sebastian Capella <sebastian.capella@...aro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Russell King <linux@....linux.org.uk>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Nicolas Pitre <nico@...aro.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Will Deacon <Will.Deacon@....com>,
	Jonathan Austin <Jonathan.Austin@....com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>,
	Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: [PATCH RFC v1 3/3] ARM hibernation / suspend-to-disk

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/