On Mon, Apr 08, 2019 at 01:58:34PM +0800, Pingfan Liu wrote:
> Beside kernel, at early boot stage, the KASLR code also needs to parse the
> crashkernel=x@y or crashkernel=ramsize-range:size[,...][@offset] option,
> and avoid to put randomized kernel in the region.
>
> Extracting the parsing related routines to lib/parse_crashkernel.c, so it
> will be handy included by other
> files.
Use this commit message for your next submission:
crash: Carve out crashkernel= cmdline parsing
Make the "crashkernel=" parsing functionality available to the early
KASLR code. Will be used by a later patch to parse crashkernel regions
which KASLR should aviod.
> Signed-off-by: Pingfan Liu <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: "H. Peter Anvin" <[email protected]>
> Cc: Baoquan He <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
> Cc: Chao Fan <[email protected]>
> Cc: "Kirill A. Shutemov" <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Vivek Goyal <[email protected]>
> CC: Hari Bathini <[email protected]>
> Cc: [email protected]
> ---
> kernel/crash_core.c | 273 ---------------------------------------------
> lib/Makefile | 2 +
> lib/parse_crashkernel.c | 289
> ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 291 insertions(+), 273 deletions(-)
And this is not how you carve out code.
First, you do a patch which does only code move. Nothing more.
In a follow on patch, you make the changes to the moved code so that it
is immediately visible what you're changing.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
