lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 06 Oct 2021 07:49:21 -0300 From: Fabio Estevam <festevam@...x.de> To: Johan Hovold <johan@...nel.org> Cc: Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>, Petr Mladek <pmladek@...e.com>, Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt <rostedt@...dmis.org>, John Ogness <john.ogness@...utronix.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org Subject: Re: [PATCH] workqueue: fix state-dump console deadlock Hi Johan, On 06/10/2021 05:11, Johan Hovold wrote: > Console drivers often queue work while holding locks also taken in > their > console write paths, something which can lead to deadlocks on SMP when > dumping workqueue state (e.g. sysrq-t or on suspend failures). > > For serial console drivers this could look like: > > CPU0 CPU1 > ---- ---- > > show_workqueue_state(); > lock(&pool->lock); <IRQ> > lock(&port->lock); > schedule_work(); > lock(&pool->lock); > printk(); > lock(console_owner); > lock(&port->lock); > > where workqueues are, for example, used to push data to the line > discipline, process break signals and handle modem-status changes. Line > disciplines and serdev drivers can also queue work on write-wakeup > notifications, etc. > > Reworking every console driver to avoid queuing work while holding > locks > also taken in their write paths would complicate drivers and is neither > desirable or feasible. > > Instead use the deferred-printk mechanism to avoid printing while > holding pool locks when dumping workqueue state. > > Note that there are a few WARN_ON() assertions in the workqueue code > which could potentially also trigger a deadlock. Hopefully the ongoing > printk rework will provide a general solution for this eventually. > > This was originally reported after a lockdep splat when executing > sysrq-t with the imx serial driver. > > Fixes: 3494fc30846d ("workqueue: dump workqueues on sysrq-t") > Cc: stable@...r.kernel.org # 4.0 > Reported-by: Fabio Estevam <festevam@...x.de> > Signed-off-by: Johan Hovold <johan@...nel.org> With this patch applied, I no longer get the lockdep splat when executing sysrq-t with the imx serial driver, thanks: Tested-by: Fabio Estevam <festevam@...x.de>
Powered by blists - more mailing lists