I've been fighting a bizarre spinlock problem... and it turns out that I
was reentrantly calling printk... the problem was that while vsprintf was
executing, it dereferenced a pointer on an unpaged page... which caused a
page fault, which caused (for me) a printk... the problem is that it
would then try to reaquire the console_lock... which it could never do.
So....
I moved the "spin_lock_irqsave(&console_lock, flags);" to after the
va_end, so that the printk code looks like this:
va_start(args, fmt);
i = vsprintf(buf + 3, fmt, args); /* hopefully i < sizeof(buf)-4 */
buf_end = buf + 3 + i;
va_end(args);
spin_lock_irqsave(&console_lock, flags);
for (p = buf + 3; p < buf_end; p++) {
instead of this:
spin_lock_irqsave(&console_lock, flags);
va_start(args, fmt);
i = vsprintf(buf + 3, fmt, args); /* hopefully i < sizeof(buf)-4 */
buf_end = buf + 3 + i;
va_end(args);
for (p = buf + 3; p < buf_end; p++) {
And everything is beautiful and things just magically work for me.
Okay, so my question is this ('cause obviously people shouldn't be
printk'ing their pagefault handlers!):
Why are we grabbing the console lock so early? Is it really neccesary
there (I don't think so)? With lots of printk's, concurrancy is
needlessly killed (vsprintf can take a relatively long time...)
Anyways, does anyone see a problem with moving it for 2.4?
-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 Jun 30 2000 - 21:45:04 EDT