lkml.org 
[lkml]   [2015]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] panic: release stale console lock to always get the logbuf printed out
    On Thu, 08 Oct 2015 11:51:13 +0200 Vitaly Kuznetsov <vkuznets@redhat.com> wrote:

    > > On Wed, 7 Oct 2015 19:02:22 +0200 Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
    > >
    > >> In some cases we may end up killing the CPU holding the console lock
    > >> while still having valuable data in logbuf. E.g. I'm observing the
    > >> following:
    > >> - A crash is happening on one CPU and console_unlock() is being called on
    > >> some other.
    > >> - console_unlock() tries to print out the buffer before releasing the lock
    > >> and on slow console it takes time.
    > >> - in the meanwhile crashing CPU does lots of printk()-s with valuable data
    > >> (which go to the logbuf) and sends IPIs to all other CPUs.
    > >> - console_unlock() finishes printing previous chunk and enables interrupts
    > >> before trying to print out the rest, the CPU catches the IPI and never
    > >> releases console lock.
    > >
    > > Why doesn't the lock-owning CPU release the console lock? Because it
    > > was stopped by smp_send_stop() in panic()?
    > >
    > > I don't recall why we stop CPUs in panic(), and of course we didn't
    > > document the reason. I guess it makes sense from the "what else can we
    > > do" point of view, but I wonder if we can just do it later on - that
    > > would fix this problem?
    >
    > We don't know for how long should we wait for the other CPU to finish
    > the output and it can take some time. In case we're rebooting after a
    > short timeout we can still end up with something in the logbuf.

    I don't understand what you're saying here.

    If we move panic()'s call to smp_send_stop() so it occurs later in
    panic(), won't this result in this CPU's messages being properly
    displayed? The currently-printing CPU will still be running and all
    the printks will proceed in the normal fashion?



    \
     
     \ /
      Last update: 2015-10-08 23:21    [W:2.447 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site