[<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