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.
Thanks,
Sebastian