[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.074 / U:1.328 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site