lkml.org 
[lkml]   [2019]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
    On 06/07/19 at 07:30pm, Borislav Petkov wrote:
    > On Mon, Jan 28, 2019 at 11:18:31AM +0100, Borislav Petkov wrote:
    > > On Mon, Jan 28, 2019 at 05:58:09PM +0800, Dave Young wrote:
    > > > Another reason is in case ,high we will need automatically reserve a
    > > > region in low area for swiotlb. So for example one use
    > > > crashkernel=256M,high, actual reserved memory is 256M above 4G and
    > > > another 256M under 4G for swiotlb. Normally it is not necessary for
    > > > most people. Thus we can not make ,high as default.
    > >
    > > And how is the poor user to figure out that we decided for her/him that
    > > swiotlb reservation is something not necessary for most people and thus
    > > we fail the crashkernel= reservation?
    > >
    > > IOW, that "logic" above doesn't make a whole lot of sense to me from
    > > user friendliness perspective.
    >
    > So to show what I mean: I'm trying to reserve a crash kernel region on a
    > box here. I tried:
    >
    > crashkernel=64M@16M
    >
    > as it is stated in Documentation/kdump/kdump.txt.
    >
    > Box said:
    >
    > [ 0.000000] crashkernel reservation failed - memory is in use.
    >
    > Oh great.
    >
    > Then I tried:
    >
    > crashkernel=64M@64M
    >
    > Box said:
    >
    > [ 0.000000] crashkernel reservation failed - memory is in use.
    >
    > So I simply did:
    >
    > crashkernel=64M
    >
    > and the box said:
    >
    > [ 0.000000] Reserving 64MB of memory at 3392MB for crashkernel (System RAM: 16271MB)
    >
    > So I could've gone a long time poking at the memory to find a suitable
    > address.
    >
    > So do you see what I mean with making this as user-friendly and as
    > robust as possible?

    Yes, it is clear to me, I absolutely agree that is not friendly :)

    Previously without KASLR, one can check /proc/iomem to find a possible
    free area and use it for next and future boot. But in case KASLR
    enabled nowadays it become harder to predict the persistent free areas.

    >
    > In this case I don't care about *where* my crash kernel is - I only want
    > to have one loaded *somewhere*.

    We would suggest people to use crashkernel=X instead. for the X@Y
    I believe it is some historic thing, it *should* be able to be obsolete
    at least on X86, (not sure other arches).
    I expect people can comment if they have some use cases requiring this
    X@Y way.

    We have modified the crashkernel=X to search 0 - 4G memory instead
    of old 0 - 896M for low memory areas, so a possible case is people who
    uses very old kexec-tools which can only load kernel to memory under
    896M.

    Another way is we just obsolete X@Y, but introduce another interface
    like crahskernel=X,max= (max will be used like the CRASH_ADDR_HIGH_MAX
    in arch/x86/kernel/setup.c)

    >
    > And the same strategy should be applied to other reservation attempts
    > - we should try hard to reserve and if we cannot reserve, then try an
    > alternating range.
    >
    > I even think that
    >
    > crashkernel=X@Y
    >
    > should not simply fail if Y is occupied but keep trying and say
    >
    > [ 0.000000] Reserving 64MB of memory at alternative address 3392MB for crashkernel (System RAM: 16271MB)
    >
    > and only fail when the user doesn't really want the kernel to try hard
    > by booting with
    >
    > crashkernel=X@Y,strict
    >
    > But that's for another day.

    Maybe X@Y,max=.. Then kernel will search begin with Y, and stop until
    max - 1;

    >
    > --
    > Regards/Gruss,
    > Boris.
    >
    > Good mailing practices for 400: avoid top-posting and trim the reply.

    Thanks
    Dave

    \
     
     \ /
      Last update: 2019-06-10 08:53    [W:3.843 / U:0.568 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site