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] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB537055DCB7D1053DE44C447AEC792@BN9PR11MB5370.namprd11.prod.outlook.com>
Date: Fri, 26 Jan 2024 02:33:43 +0000
From: "Chang, Junxiao" <junxiao.chang@...el.com>
To: John Ogness <john.ogness@...utronix.de>, "bigeasy@...utronix.de"
	<bigeasy@...utronix.de>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: "Li, Hao3" <hao3.li@...el.com>, "Li, Lili" <lili.li@...el.com>, "Gao,
 Jianfeng" <jianfeng.gao@...el.com>, "linux-rt-users@...r.kernel.org"
	<linux-rt-users@...r.kernel.org>
Subject: RE: [PATCH 2/2] printk: nbcon: check uart port is nbcon or not in
 nbcon_release


> The release needs to undo what acquire did. Why should it have its own checks that would cause it to _not_ undo what acquire did?
>

I agree with you that release needs to be undo what acquire did. The problem is sometimes it might do release while it didn't acquire. In nbcon_acquire, it checks current uart_port is nbcon or not. If it is not nbcon, it returns without locking anything. So in nbcon_release, it should have this checking as well. If current uart_port is not nbcon, it should not do any lock release, this is reason I added this checking in nbcon_release.

For example, there are two uart port ttyS0 and ttyS4, ttyS0 is console and nbcon. ttyS4 is not console or nbcon. When ttyS4 uart port is shutdown, it firstly calls nbcon_acquire, then calls nbcon_release in "serial8250_do_shutdown". During nbcon_acquire, it locks nothing because current uart is not nbcon(There is uart_is_nbcon checking in nbcon_acquire). When it calls nbcon_release, it should not release anything either because it is not nbcon - it doesn't lock anything in nbcon_acquire. But with current code logic, it will release nbcon lock which should not be released.

Regards,
Junxiao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ