[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH #2] console lock grabbed too early in printk...
    Chris Lattner wrote:
    > ...
    > Wait, back up, let me get this straight. There are two situations here:


    you're right. printk() can deadlock. Bear in mind that any
    deadlock-detector for printk() needs to be aware of which CPU holds the
    spinlock. That is, a simple

    if (!spin_trylock(&console_lock))


    is wrong.

    You should only take avoiding action if the lock is held by this_cpu.
    This implies that in all places where the console lock is taken you'll
    need to record which CPU holds it. Not too hard. Alternatively, just
    put an upper bound on the spin duration (one second would suffice).

    You have a choice of three actions when the deadlock situation is

    1: Return without printing

    I think this is bad. You're almost certainly throwing
    away a vital piece of information.

    2: Save the message somewhere and print it out later.

    This is hard. Probably the safest approach is to create
    a 'static char backup_buf[1024]' and use that instead,
    poll it later.

    3: Bust the spinlock and make the current printk() come out.

    I think this is the best approach, but it's tricky to
    get right. Perhaps you should BUG() immediately after
    doing the output.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.031 / U:59.444 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site