Messages in this thread |  | | | Date | Sun, 2 Jul 2000 12:49:51 -0700 (PDT) | | From | Chris Lattner <> | | Subject | Re: [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/
|  |