Messages in this thread | | | Date | Sun, 02 Jul 2000 18:40:56 +1000 | From | Andrew Morton <> | Subject | Re: [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:
Chris,
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
printk() { if (!spin_trylock(&console_lock)) do_something_strange()
}
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 detected:
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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |