lkml.org 
[lkml]   [2014]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2014-02-22 08:41    [W:0.108 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site