Messages in this thread | | | Date | Sun, 02 Jan 2005 13:41:34 -0800 | From | "Randy.Dunlap" <> | Subject | Re: printk loglevel policy? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |