Received-SPF: pass (google.com: domain of linux-kernel+bounces-39543-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: "Chang, Junxiao" <junxiao.chang@intel.com>
To: John Ogness <john.ogness@linutronix.de>, "bigeasy@linutronix.de"
	<bigeasy@linutronix.de>, "tglx@linutronix.de" <tglx@linutronix.de>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
CC: "Li, Hao3" <hao3.li@intel.com>, "Li, Lili" <lili.li@intel.com>, "Gao,
 Jianfeng" <jianfeng.gao@intel.com>, "linux-rt-users@vger.kernel.org"
	<linux-rt-users@vger.kernel.org>
Subject: RE: [PATCH 2/2] printk: nbcon: check uart port is nbcon or not in
 nbcon_release
Thread-Topic: [PATCH 2/2] printk: nbcon: check uart port is nbcon or not in
 nbcon_release
Thread-Index: AQHaTb7bx9lc/bq9QEex0jEUkq3YtrDovAmAgAKgL4A=
Date: Fri, 26 Jan 2024 02:33:43 +0000
Message-ID: <BN9PR11MB537055DCB7D1053DE44C447AEC792@BN9PR11MB5370.namprd11.prod.outlook.com>
References: <BN9PR11MB5370AED9C562F9DA75093557EC742@BN9PR11MB5370.namprd11.prod.outlook.com>
 <20240123054033.183114-1-junxiao.chang@intel.com>
 <20240123054033.183114-3-junxiao.chang@intel.com>
 <87il3j9hpo.fsf@jogness.linutronix.de>
In-Reply-To: <87il3j9hpo.fsf@jogness.linutronix.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?cQb6GAj87JiLUsrOwFTSdKBK+oFcaPW+Ap3V5tQNGDod3VZM085FXEtp7huU?=
 =?us-ascii?Q?XTViiUFyWzZGynSDVtfykuThZR/2VkVFDLJIPAEphOE4YRdFVqAKyy4fV5kV?=
 =?us-ascii?Q?VJv1ETcDtVQ6m4sVOVgjOsgW/fdv5LrR6kaE6kbeb93pWoah7CY4/I+owSbK?=
 =?us-ascii?Q?coQyuhtjx0GdBGhvGhdgqTCxCp+jQ5Md8bSEDhWou4tVn14DYxYst5LLfKSu?=
 =?us-ascii?Q?+XfKC9aMaGIJ7OpwN1vdWWlqJT0hM0ThR4wQHlyIUqflVcHVR3cjvkoSnfjY?=
 =?us-ascii?Q?Uvz+t8jyXUyX7dnj6S8+ipEIrvblovTn7QJhmnqsFUrSv7w5+Ggk1SQ41akF?=
 =?us-ascii?Q?HZag62WIpm4KrgW1bopHVeaA2kwo+WOVk5uEsn3rsQOTZlZTd8kPPe08WAPj?=
 =?us-ascii?Q?z5BszOeHeRMGGL0fpGVguE5ODrSVYsKyOrpTTrZCe6al0lbBLC4zLwq2fkeB?=
 =?us-ascii?Q?kFfJ1SxeZKycfpi5npMOD+mGA1lxq1Kkcxk2wj8ijLenQRs0TfaL2egte/Np?=
 =?us-ascii?Q?1ybovSNjHayp+OYdjyppWFlnLS+k6KP5luVxjn2XFIJbUM0chH4dHD/N7LS5?=
 =?us-ascii?Q?e7HPqroi5PZ3kq+pDuuEQGGdp6whATzpvDPnoNifrJ13mYVS8SVczeGJSWLN?=
 =?us-ascii?Q?pcaapIUMM8Dx1sE1961k/+ajFQMdCNdrmO6qqdY5aTJwrz1pqAnzdWVKwvMh?=
 =?us-ascii?Q?7cWd2o4bo1dsnvtOWedtk19s586wrjHPQ35Jv9aMm403BmAE61mKmveG4kWO?=
 =?us-ascii?Q?5j6E7GEm7Lc4XuIxi1fVsc9IRPmc5mXtbruaRimK/N+JD/wO4lWOODunY6Hd?=
 =?us-ascii?Q?FJYBO0XOS54eZt7HKIyaofq6BZueO4wkJxxqwN7Qbh1bVfl/lr5e0u0wvSbe?=
 =?us-ascii?Q?T/4HVl3wVAXTN0BBqxnycKr+GgJv3KRI4PglaFeduIZJKgGnYcAh8pHsMDoD?=
 =?us-ascii?Q?EKeeDvPE+84t+avym44sri+2Xoicsg/7LT6Q5rxLfpiWoLmlC95Ue9pX6KEA?=
 =?us-ascii?Q?wERcII5AWKhlkuNGDFxya2XygKA+oMQfWYmiW4TniNKwbuIPCNM2ZKLcws4V?=
 =?us-ascii?Q?yIqsNpDa0SCA6lZpIFY1Btv94ZE1cv9U1q1vQF3ZBGSidvu60m0iBLyCF7Wj?=
 =?us-ascii?Q?TgCnrLf6feIPd5i6EPDMxFa969UlefKv2ZyPgvmD473BvsHui+BHNlCafDin?=
 =?us-ascii?Q?/+eqi6sq5ROyd/6g3n3Y26wALfkfE9RMBoQzokYNqrgeiCyDZ1xfjIX3Agpz?=
 =?us-ascii?Q?mYXOZLsCrTQ4npl5u/Us5GyI6Xb40d2gtsZBK8M4Y+kqjX2XsgNXzaAd1fSd?=
 =?us-ascii?Q?6oXCvxHm1u544s/EccGEFyErW71NhjwVYUkelIn8/a+Ytalv9rMSN8aEl5t1?=
 =?us-ascii?Q?ETzu/7Evpq7T5yMfsdIsWWm/Byh52bIoxczGC7GLoMWWbRqdRN2eeEPyJDy6?=
 =?us-ascii?Q?ki67QJc2rEkQmnraoNKgZZcZTtOk95B7JGjRi1nQYHrqnL+unq+b7BuUfaHi?=
 =?us-ascii?Q?1FFOwVGNST3ZioZkib9HZnEcF9XcTBFiiobqMLsS+wUC7OQN6QgwJQETtawd?=
 =?us-ascii?Q?DngX/Vs154F5fc1t2NPFG0Df1rDP17YomYfeu8jX?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5370.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ba761cb-f439-41a9-de0f-08dc1e173740
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2024 02:33:43.9573
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ro15ibRLYT5tWcMdMdTfpNAGcBXDXpgX+MPiIleaVcakjM3xZKa+EThtRyceFg3kMDHAWOc/aqNspkpL7SdB1Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6752
X-OriginatorOrg: intel.com


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

I agree with you that release needs to be undo what acquire did. The proble=
m is sometimes it might do release while it didn't acquire. In nbcon_acquir=
e, it checks current uart_port is nbcon or not. If it is not nbcon, it retu=
rns without locking anything. So in nbcon_release, it should have this chec=
king 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_shu=
tdown". During nbcon_acquire, it locks nothing because current uart is not =
nbcon(There is uart_is_nbcon checking in nbcon_acquire). When it calls nbco=
n_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