Re: console_lock too early in printk???

[Chris Lattner]

Moral of this story:  Don't you DARE use printk for debugging, you might
introduce more problems than you started with.  :)

On a more serious note... couldn't issues like these be temporarily side
stepped by making the console_lock recursive, similar to the monster
kernel_lock?  You could keep one copy of the entrance count with the lock
itself, rather than one copy each in the "current" task_struct...

-Chris

On Sat, 1 Jul 2000, Andrew Morton wrote:

> There's one thing which bugs me about the console code.
> 
> console_softint() calls change_console() calls kill_proc().
> 
> This means that we're delivering a signal from within a softirq.  Looks
> like it can call wake_up_process(), kmalloc(), etc, etc.  It also checks
> the permissions on *current!
> 
> Is all this activity legitimate from within a tasklet?
> 
> Secondly, this is all done with console_lock held, so if anyone does a
> printk() will it not deadlock?
>