lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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:

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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:1.033 / U:2.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site