lkml.org 
[lkml]   [2023]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectpanic context: was: Re: [PATCH printk v2 04/11] printk: nbcon: Provide functions to mark atomic write sections
    (2nd attempt with with Linus really in Cc).

    Adding Linus into Cc. I would like to be sure about the flushing
    of atomic consoles in panic context.

    > During the demo at LPC2022 we had the situation that there was a large
    > backlog when a WARN was hit. With current mainline the first line of the
    > WARN is put into the ringbuffer and then the entire backlog is flushed
    > before storing the rest of the WARN into the ringbuffer. At the time it
    > was obvious that we should finish storing the WARN message and then
    > start flushing the backlog.

    This talks about the "emergency" context (WARN/OOPS/watchdog).
    The system might be in big troubles but it would still try to continue.

    Do we really want to defer the flush also for panic() context?

    I ask because I was not on LPC 2022 in person and I do not remember
    all details.

    Anyway, the deferred flush works relatively well for the "emergency" context:

    + flushed from nbcon_atomic_exit()
    + printk kthread might emit the messages while they are being added

    But it is tricky in panic(), see 8th patch at
    https://lore.kernel.org/r/20230919230856.661435-9-john.ogness@linutronix.de

    + nbcon_atomic_exit() is called only in one code path.

    + nbcon_atomic_flush_all() is used in other paths. It looks like
    a "Whack a mole" game to me.

    + messages are never emitted by printk kthread either because
    CPUs are stopped or the kthread is not allowed to get the lock[*]

    I see only one positive of the explicit flush. The consoles would
    not delay crash_exec() and the crash dump might be closer to
    the point where panic() was called.

    Otherwise I see only negatives => IMHO, we want to flush atomic
    consoles synchronously from printk() in panic().

    Does anyone really want explicit flushes in panic()?

    [*] Emitting messages is explicitly blocked on non-panic CPUs. It
    increases the change that panic-CPU would be able to take
    the console lock the safe way.

    Best Regards,
    Petr

    \
     
     \ /
      Last update: 2023-10-06 14:55    [W:2.711 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site