lkml.org 
[lkml]   [2022]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 24/30] panic: Refactor the panic path
    From
    On 19/05/2022 20:45, Baoquan He wrote:
    > [...]
    >> I really appreciate the summary skill you have, to convert complex
    >> problems in very clear and concise ideas. Thanks for that, very useful!
    >> I agree with what was summarized above.
    >
    > I want to say the similar words to Petr's reviewing comment when I went
    > through the patches and traced each reviewing sub-thread to try to
    > catch up. Petr has reivewed this series so carefully and given many
    > comments I want to ack immediately.
    >
    > I agree with most of the suggestions from Petr to this patch, except of
    > one tiny concern, please see below inline comment.

    Hi Baoquan, thanks! I'm glad you're also reviewing that =)


    > [...]
    >
    > I like the proposed skeleton of panic() and code style suggested by
    > Petr very much. About panic_prefer_crash_dump which might need be added,
    > I hope it has a default value true. This makes crash_dump execute at
    > first by default just as before, unless people specify
    > panic_prefer_crash_dump=0|n|off to disable it. Otherwise we need add
    > panic_prefer_crash_dump=1 in kernel and in our distros to enable kdump,
    > this is inconsistent with the old behaviour.

    I'd like to understand better why the crash_kexec() must always be the
    first thing in your use case. If we keep that behavior, we'll see all
    sorts of workarounds - see the last patches of this series, Hyper-V and
    PowerPC folks hardcoded "crash_kexec_post_notifiers" in order to force
    execution of their relevant notifiers (like the vmbus disconnect,
    specially in arm64 that has no custom machine_crash_shutdown, or the
    fadump case in ppc). This led to more risk in kdump.

    The thing is: with the notifiers' split, we tried to keep only the most
    relevant/necessary stuff in this first list, things that ultimately
    should improve kdump reliability or if not, at least not break it. My
    feeling is that, with this series, we should change the idea/concept
    that kdump must run first nevertheless, not matter what. We're here
    trying to accommodate the antagonistic goals of hypervisors that need
    some clean-up (even for kdump to work) VS. kdump users, that wish a
    "pristine" system reboot ASAP after the crash.

    Cheers,


    Guilherme

    \
     
     \ /
      Last update: 2022-05-20 13:25    [W:2.914 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site