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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 15 Feb 2013 09:30:16 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>, Jiri Slaby <jslaby@...e.cz>,
	Xinyu Chen <xinyu.chen@...escale.com>,
	Dirk Behme <dirk.behme@...bosch.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Tim Sander <tim@...eglstein.org>,
	Sascha Hauer <s.hauer@...gutronix.de>, stable@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH] serial: imx: Fix recursive locking bug

On Thu, Feb 14, 2013 at 09:01:06PM +0100, Thomas Gleixner wrote:
> commit 9ec1882df2 (tty: serial: imx: console write routing is unsafe
> on SMP) introduced a recursive locking bug in imx_console_write().
> 
> The callchain is:
> 
> imx_rxint()
>   spin_lock_irqsave(&sport->port.lock,flags);
>   ...
>   uart_handle_sysrq_char();
>     sysrq_function();
>       printk();
>         imx_console_write();
>           spin_lock_irqsave(&sport->port.lock,flags); <--- DEAD
> 
> The bad news is that the kernel debugging facilities can dectect the
> problem, but the printks never surface on the serial console for
> obvious reasons.
> 
> There is a similar issue with oops_in_progress. If the kernel crashes
> we really don't want to be stuck on the lock and unable to tell what
> happened.
> 
> In general most UP originated drivers miss these checks and nobody
> ever notices because CONFIG_PROVE_LOCKING seems to be still ignored by
> a large number of developers.
> 
> The solution is to avoid locking in the sysrq case and trylock in the
> oops_in_progress case.
> 
> This scheme is used in other drivers as well and it would be nice if
> we could move this to a common place, so the usual copy/paste/modify
> bugs can be avoided.

I agree, making this easier to handle would be nice, patches are always
accepted :)

thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ