printk() with a spin-lock held.

printk() with a spin-lock held.

[Richard B. Johnson]

Linux-2.6.9 will bug-check and halt if my code executes
a printk() with a spin-lock held.

Is this the intended behavior? If so, NotGood(tm).

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
                  98.36% of all statistics are fiction.

Re: printk() with a spin-lock held.

[Lee Revell]

On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
> Linux-2.6.9 will bug-check and halt if my code executes
> a printk() with a spin-lock held.
> 
> Is this the intended behavior?

Yes.  printk() can sleep.  No sleeping with a spinlock held.

> If so, NotGood(tm).

See above.  If you think you can improve the situation, patches are
welcome, as always.

Lee

Re: printk() with a spin-lock held.

[Andrew Morton]

Lee Revell <rlrevell@joe-job.com> wrote:
>
> On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
> > Linux-2.6.9 will bug-check and halt if my code executes
> > a printk() with a spin-lock held.
> > 
> > Is this the intended behavior?
> 
> Yes.  printk() can sleep.  No sleeping with a spinlock held.
> 

printk() does not sleep and may be called from any context except

a) NMI handlers and

b) when holding a scheduler runqueue->lock while klogd is running.

Re: printk() with a spin-lock held.

[Nick Piggin]

Lee Revell wrote:
> On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
> 
>>Linux-2.6.9 will bug-check and halt if my code executes
>>a printk() with a spin-lock held.
>>
>>Is this the intended behavior?
> 
> 
> Yes.  printk() can sleep.  No sleeping with a spinlock held.
> 

You can call printk anywhere (except from the scheduler).
Or if you're doing tricky things with preempt.

> 
>>If so, NotGood(tm).
> 
> 
> See above.  If you think you can improve the situation, patches are
> welcome, as always.
> 

In this case, the patch would be to himself though.

Re: printk() with a spin-lock held.

[Lee Revell]

On Fri, 2004-10-22 at 22:27 -0700, Andrew Morton wrote:
> Lee Revell <rlrevell@joe-job.com> wrote:
> >
> > On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
> > > Linux-2.6.9 will bug-check and halt if my code executes
> > > a printk() with a spin-lock held.
> > > 
> > > Is this the intended behavior?
> > 
> > Yes.  printk() can sleep.  No sleeping with a spinlock held.
> > 
> 
> printk() does not sleep and may be called from any context except
> 
> a) NMI handlers and
> 
> b) when holding a scheduler runqueue->lock while klogd is running.
> 

Oops, thinko.  Thanks.

Lee

Re: printk() with a spin-lock held.

[Richard B. Johnson]

On Fri, 22 Oct 2004, Lee Revell wrote:

> On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
>> Linux-2.6.9 will bug-check and halt if my code executes
>> a printk() with a spin-lock held.
>>
>> Is this the intended behavior?
>
> Yes.  printk() can sleep.  No sleeping with a spinlock held.
>
>> If so, NotGood(tm).
>
> See above.  If you think you can improve the situation, patches are
> welcome, as always.
>
> Lee
>

I recall that printk() useds to just write stuff into a buffer,
that the buffer (the same buffer used for dmesg), was written
out only when it was safe to do so.


Now, if printk() can't do that anymore, how does one de-bug
ISR code? Or do you just heave it off the cliff and hope that
it flies?


Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
                  98.36% of all statistics are fiction.

Re: printk() with a spin-lock held.

[Lee Revell]

On Mon, 2004-10-25 at 08:32 -0400, Richard B. Johnson wrote:
> I recall that printk() useds to just write stuff into a buffer,
> that the buffer (the same buffer used for dmesg), was written
> out only when it was safe to do so.
> 
> 
> Now, if printk() can't do that anymore, how does one de-bug
> ISR code? Or do you just heave it off the cliff and hope that
> it flies?

No, it can, I was wrong.  I was thinking of some other function.

Lee

Re: printk() with a spin-lock held.

[linux-os]

On Mon, 25 Oct 2004, Lee Revell wrote:

> On Mon, 2004-10-25 at 08:32 -0400, Richard B. Johnson wrote:
>> I recall that printk() useds to just write stuff into a buffer,
>> that the buffer (the same buffer used for dmesg), was written
>> out only when it was safe to do so.
>>
>>
>> Now, if printk() can't do that anymore, how does one de-bug
>> ISR code? Or do you just heave it off the cliff and hope that
>> it flies?
>
> No, it can, I was wrong.  I was thinking of some other function.
>
> Lee

Yes. I think that the problem I observed was when the ISR
wouldn't reset the interrupt because the hardware was broken.
This makes the level-interrupt stay active forever. I put
a printk() in the ISR and I got a bug-check because printk
didn't like me.

Apparently, if the printk() buffer gets full, it bug-checks.
The behavior used to be that it would just dump overflow
on the floor.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
                  98.36% of all statistics are fiction.