lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateSun, 2 Jul 2000 12:49:51 -0700 (PDT)
FromChris Lattner <>
SubjectRe: [PATCH #2] console lock grabbed too early in printk...

> 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

> 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).

That is what I'm doing in patches #2&3... looking at current to see if the
processor that has the lock is trying to reaquire it. Now I'm not
shooting for a "prevent all recursive uses of console_lock" tactic, but
that could be an easy extension... and it might just make sense. I'm not
sure if using current is the right way to detect this... but I _think_
it's okay? :)

> 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.

Yeah, just "dropping" messages without any indication that something
happened is baaaad... :)
> 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.

That is possible... but "what is enough" if it could reenter 1 time,
what's to prevent it from reentering 2 times? I don't think this solution
would really be accepted...

> 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.

or
4: Count failed attempts to print and print that number out during the
next successful printk. This has the advantage that the user knows that
_SOMETHING_ happened... but also that execution can continue and move
on... This is the technique my patch #3 uses...

-Chris


-
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    [from the cache]
©2003-2010