Re: printk loglevel policy?

[Randy.Dunlap]

Jim Nelson wrote:
> Alan Cox wrote:
>
> > On Gwe, 2004-12-31 at 02:20, Coywolf Qi Hunt wrote:
> >
> > > Hi all,
> > > Recently, I've seen a lot of add loglevel to printk patches. grep 
> > > 'printk("' -r | wc shows me 2433. There are probably 2433 printk
> > > need to patch, is it?  What's this printk loglevel policy, all these
> >
> >
> >
> > You would need to work out which were at the start of a newline - most
> > of them are probably just fine and valid
>
> That reminds me of a question I've had inthe back of my head.  When you 
> have a SMP system wouldn't it be possible to have:
>
> CPU 1 (running func1)    CPU 2 (running func2)
>  |             |
>  printk ("foo...");     |
>  |            printk ("bleh\n");
>  printk ("finished\n);     |
>             printk ("readout from bleh\n";
>
> Is that possible?  Especially if the process on CPU 1 slept on a 
> semaphore or something similar?
>
> Or does printk() do some tracking that I didn't see as to where in the 
> kernel the strings are coming from?

That kind of garbled output has been known to happen, but
the <console_sem> is supposed to prevent that (along with
zap_locks() in kernel/printk.c).

If it still happens, it needs to be fixed.
David Howells (RH) has posted patches that fix it.

--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/