Messages in this thread | | | Date | Mon, 24 Mar 2008 13:24:24 +0100 | From | Peter Zijlstra <> | Subject | [PATCH 0/2] printk vs rq->lock and xtime lock |
| |
Hi Linus,
As to the regression reported by Marcin; what happens is that we invoke printk() while holding the xtime lock for writing. printk() will call wake_up_klogd() which tries to enqueue klogd on some rq.
The known deadlock here is calling printk() while holding rq->lock, which would then try to recusively lock the rq again when trying to wake klogd.
The new deadlock is due to task enqueues setting an hrtimer, which requires reading the time, which will result in a live-lock when the printk() call- site is holding the xtime lock for writing.
Thomas would like to preserve the printk() information if possible, hence my proposal of printk_nowakeup(). It will do everything printk() normally does, except ommit to wake up of klogd. The call is explicitly not EXPORTed so that its use is confined to core kernel code.
Marcin, could you please test these two patches to confirm they do indeed solve your issue as well?
Peter
| |