Re: [PATCH 2/3] netpoll: netconsole

[Andrew Morton]

Mitchell Blank Jr <mitch@xxxxxxxxxx> wrote:
>
> Mitchell Blank Jr wrote:
> > The netconsole problem is only if the net driver calls printk() with
> > its spinlock held (but when not called from netconsole).  Then printk()
> > won't know that it's unsafe to re-enter the network driver.
> 
> BTW, this isn't neccesarily a netconsole-only thing.  For instance, has
> anyone ever audited all of the serial and lp drivers to make sure that
> nothing they call can call printk() while holding a lock?  This sounds
> fairly serious - we could have any number of simple error cases that would
> cause a deadlock with the right "console=" setting.
> 
> It'd be interesting if we could do something like:
>   1. For every function that appears as a "struct console -> write()" call,
>      follow every possible code path and make a list of every lock that they
>      can try to acquire exclusively.
>   2. Then scan the entire code base see if we ever call can printk() while
>      holding that same lock.

If a driver calls printk() while in ->write(), printk will fail to acquire
the console_sem.  The printk output will be buffered in log_buf[].  When
->write() releases console_sem it will then display the buffered text.

So the deadlocks to which you refer can only happen when the console driver
calls printk while holding driver locks, in a code path where console_sem
is not held.

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