> 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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:12 EST