printk vs rq->lock and xtime lock
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 14 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | printk_nowakeup()include/ kernel/ | +34 | 0 replies | |
| 2/2 | time: xtime lock vs printkkernel/ | +5 | 1 reply |
Reviews trailers per patch
None of the 2 patches has a Reviewed-by or Acked-by of their own; the series has one for all of them.
| Patch | Marcin Slusarz | Steven Rostedt | Paul E. McKenney | Peter Zijlstra |
|---|---|---|---|---|
| Series | T-b | A-b A-b | A-b | A-b |
| 1/2 | ||||
| 2/2 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 4 reviewers.
Cover letter [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