Linux-kernel mailing list archive 2000-26,: Re: console_lock too early in printk???

# Re: console_lock too early in printk???

Chris Lattner (sabre@skylab.org)
Sat, 1 Jul 2000 00:23:59 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Manfred Spraul: "Re: spinlocks() are severely broken in 2.2.X and 2.4.X for modules"
- Previous message: Vojtech Pavlik: "Re: [patch] Make UDMA66 work on VIA boards"

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?
>

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

- Next message: Manfred Spraul: "Re: spinlocks() are severely broken in 2.2.X and 2.4.X for modules"
- Previous message: Vojtech Pavlik: "Re: [patch] Make UDMA66 work on VIA boards"