[lkml]   [2008]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] printk deadlocks if called with runqueue lock held

    On Thu, 17 Jan 2008, Andrew Morton wrote:
    > A "well-known" problem which few know about ;)

    And now I feel less ignorant.

    > Anyway you should be developing with all debug options enabled and that
    > includes NMI watchdog so there.

    hehe, I did have NMI on the whole time. It's that I also had modifications
    in try_to_wakeup, so seeing that in the backtrace, I thought I was the one
    screwing up. But I was still certain that it was my code locking up.

    > >
    > > Calling printk with interrupts disabled should only be done for
    > > emergencies and debugging anyway.
    > >

    > > + * held, this will deadlock. We don't have access to the runqueue
    > > + * lock from here, but just checking for interrupts disabled
    > > + * should be enough.
    > > + */
    > > + if (!irqs_disabled() && wake_klogd)
    > > wake_up_klogd();
    > > }
    > > EXPORT_SYMBOL(release_console_sem);
    > this looks fairly foul. Might cause problems if one CPU is stuck with
    > interrupts off spewing printks?

    Well, we have more than one problem if that is happening.

    > Couldn't you maintain a sched-hackers-only printk patch which adds a
    > sched_printk() which avoids the wakeup or something like that?

    Actually, the code that did trigger it was part of the latency_tracer
    code doing the wakeup latency timings. Theres a printk that happens when
    we trigger the max latency, and it prints from the scheduler.

    So this was perfect to lock up every time.

    -- Steve

     \ /
      Last update: 2008-01-18 03:01    [W:0.022 / U:1.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site