console_lock too early in printk???

[Chris Lattner]

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