Messages in this thread | | | From | Konstantin Khlebnikov <> | Date | Thu, 18 Jul 2019 14:07:20 +0300 | Subject | Re: [PATCH 2/2] printk/panic/x86: Allow to access printk log buffer after crash_smp_send_stop() |
| |
On Thu, Jul 18, 2019 at 1:48 PM Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote: > > On (07/16/19 09:28), Petr Mladek wrote: > [..] > > +int printk_bust_lock_safe(bool kdump_smp_stop) > > { > > if (!raw_spin_is_locked(&logbuf_lock)) > > return 0; > > > > - if (num_online_cpus() == 1) { > > + if (num_online_cpus() == 1 || kdump_smp_stop) { > > debug_locks_off(); > > raw_spin_lock_init(&logbuf_lock); > > return 0; > > Let me test the waters. Criticize the following idea: > > Can we, sort of, disconnect "supposed to be dead" CPUs from printk() > so then we can unconditionally re-init printk() from panic-CPU? > > We have per-CPU printk_state; so panic-CPU can set, let's say, > DEAD_CPUS_TELL_NO_TALES bit on all CPUs but self, and vprintk_func() > will do nothing if DEAD_CPUS_TELL_NO_TALES bit set on particular > CPU. Foreign CPUs are not even supposed to be alive, and smp_send_stop() > waits for IPI acks from secondary CPUs long enough on average (need > to check that) so if one of the CPUs is misbehaving and doesn't want > to die (geez...) we will just "disconnect" it from printk() to minimize > possible logbuf/console drivers interventions and then proceed with > panic; assuming that misbehaving CPUs are actually up to something > sane. Sometimes, you know, in some cases, those CPUs are already dead: > either accidentally powered off, or went completely nuts and do nothing, > etc. etc. but we still can kdump() and console_flush_on_panic().
Good idea. Panic-CPU could just increment state to reroute printk into 'safe' per-cpu buffer.
> > -ss
| |