Initial implementation of kdump for ARM
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest posting 9/90 of 8 patches 0 repliesNew
- v2 posting 8/90 of 8 patches 0 repliesSuperseded
- v2 posting 7/90 of 8 patches 0 repliesSuperseded
Earlier versions · 6
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v2 posting 6/9 | 0 of 8 patches | 0 replies | Superseded | |
| v2 posting 5/9 | 0 of 8 patches | 0 replies | Superseded | |
| v2 posting 4/9 | 0 of 8 patches | 0 replies | Superseded | |
| v2 posting 3/9 | 0 of 8 patches | 0 replies | Superseded | |
| v2 posting 2/9 | 0 of 8 patches | 0 replies | Superseded | |
| v2 posting 1/9 | 0 of 8 patches | 0 replies | Superseded |
Patches in v2 posting 9/9 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH v2 0/8] Initial implementation of kdump for ARM
Quoted 7 lines · Simon Horman
Quoted 7 lines
Quoted 2 lines
And it would still be nice to not corrupt the page table of the crashing context.
What you're then asking for is the crashing kernel to allocate 16K of memory to setup some page tables, and then context switch to that table so that the MMU can be turned off.
Quoted 8 lines
Quoted 1 line
That's never going to be anywhere near reliable.
Can this be addresses by allocating the memory at the time that kdump is loaded rather than when it is executed (because of a crash)?
IIRC, x86 uses a double page table approach and it is done reliably.
We could do that.
Admittedly, this is getting very "hacky", but if we want to set up a new L1 page table in which we really only need one entry (for the code running until we're sure the MMU is off), we could set up this one entry all by itself placed at just the right offset within a page and then set the PGD to point at the start of that page (since we're talking about mappings for 0x00000000-0x40000000). The rest of the page could still be used for other stuff - and even if this turns out to be more trouble than it's worth, the other 12KB do not need to be allocated.
However, I still think we could work within the old L1 table and:
1) only modify one entry
2) save that entry before overwriting it
Regards,
Per