Messages in this thread | | | Subject | printk() vs tty_io | From | Peter Zijlstra <> | Date | Tue, 13 Dec 2011 20:33:23 +0100 |
| |
Hi tty folks,
I've been poking at reducing the constraints on printk(), like make it work under rq->lock etc..
Aside from a fwd port of the patch that abuses the console_sem.lock: https://lkml.org/lkml/2011/6/9/298 and a few other not so very pretty patches, I ran into the following lockdep splat (using a not so very pretty lockdep early_printk() patch):
watchdog/0/10 is trying to acquire lock: ((console_sem).lock){-.-...}, at: but task is already holding lock: (&rt_rq->rt_runtime_lock){-.-...}, at: which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #5 (&rt_rq->rt_runtime_lock){-.-...}: -> #4 (&rq->lock){-.-.-.}: -> #3 (&p->pi_lock){-.-.-.}: -> #2 (&tty->write_wait){-.-...}: -> #1 (&port_lock_key){-.-...}: -> #0 ((console_sem).lock){-.-...}:
It turns out that writing to a console does wakeups due to tty_io.c.
My question is basically, is there a feasible way around doing these wakeups from the console::write() path? Everything I thought of was really quite horrible... and very likely would break stuff since I'm not that well versed in the whole tty thing.
| |