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
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?
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
On Sun, 02 Jan 2005 13:41:34 -0800,
"Randy.Dunlap" <[email protected]> wrote:
>Jim Nelson wrote:
>> 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).
Using multiple calls to printk to print a single line has always been
subject to the possibility of interleaving on SMP. We just live with
the risk. Printing a complete line in a single call to printk is
protected by various locks. Print a line in multiple calls is not
protected. If it bothers you that much, build up the line in a local
buffer then call printk once.
Keith Owens wrote:
> On Sun, 02 Jan 2005 13:41:34 -0800,
> "Randy.Dunlap" <[email protected]> wrote:
>
>>Jim Nelson wrote:
>>
>>>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).
>
>
> Using multiple calls to printk to print a single line has always been
> subject to the possibility of interleaving on SMP. We just live with
> the risk. Printing a complete line in a single call to printk is
> protected by various locks. Print a line in multiple calls is not
> protected. If it bothers you that much, build up the line in a local
> buffer then call printk once.
True, I was thinking about the single line case, which I
have seen garbled/mixed in the past (on SMP). Hopefully
that one is fixed.
--
~Randy
Randy.Dunlap wrote:
> Keith Owens wrote:
>
>> On Sun, 02 Jan 2005 13:41:34 -0800, "Randy.Dunlap" <[email protected]>
>> wrote:
>>
>>> Jim Nelson wrote:
>>>
>>>> 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).
>>
>>
>>
>> Using multiple calls to printk to print a single line has always been
>> subject to the possibility of interleaving on SMP. We just live with
>> the risk. Printing a complete line in a single call to printk is
>> protected by various locks. Print a line in multiple calls is not
>> protected. If it bothers you that much, build up the line in a local
>> buffer then call printk once.
>
>
> True, I was thinking about the single line case, which I
> have seen garbled/mixed in the past (on SMP). Hopefully
> that one is fixed.
>
Okay, that answered my question. Is is frowned upon to use strncat/strcat in the
kernel? I have yet to see any use of them outside of the definition in
lib/string.c. It would seem to be faster (less potential contention for the
printk locks).
Keith Owens <[email protected]> wrote:
> >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).
>
> Using multiple calls to printk to print a single line has always been
> subject to the possibility of interleaving on SMP. We just live with the
> risk. Printing a complete line in a single call to printk is protected by
> various locks. Print a line in multiple calls is not protected. If it
> bothers you that much, build up the line in a local buffer then call printk
> once.
The oops writer breaks the locks. It's _really_ annoying when oopses happen
simultaneously on separate CPUs - the oops reports end up interleaved
char-by-char.
My patch serialised oops writing.
David