linux-kernel - Re: [PATCH v2 4/7] remoteproc: core: Use cleanup.h macros to simplify lock handling

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: <20251014105530.GB14479@nxa18884-linux.ap.freescale.net>
Date: Tue, 14 Oct 2025 18:55:30 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Andrew Davis <afd@...com>
Cc: Peng Fan <peng.fan@....com>, Bjorn Andersson <andersson@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>,
	Daniel Baluta <daniel.baluta@....com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 4/7] remoteproc: core: Use cleanup.h macros to
 simplify lock handling

Hi Andrew,

Thanks for your reviewing.

On Fri, Oct 10, 2025 at 07:34:13PM -0500, Andrew Davis wrote:
>On 10/10/25 7:24 AM, Peng Fan wrote:
>> Replace manual mutex_lock/unlock and error-handling patterns with cleanup.h
>> macros (ACQUIRE, ACQUIRE_ERR, and scoped_guard) to streamline lock
>> management. As a result, several goto labels and redundant error paths are
>> eliminated.
>> 
>> -
>> -	if (rproc->state == RPROC_CRASHED) {
>> +	scoped_guard(mutex, &rproc->lock) {
>
>Not sure this one is worth switching to scoped_guard as is doesn't save
>us needing the goto out label. Plus it adds indent to a bunch of lines.

I was thinking to align the usage of cleanup API, avoiding mix the usage
the cleanup API and direct usage of mutex_lock/unlock API.

Considering the deadlock report [1], we may need to rethink the lock
scope in remoteproc_core.c. I gave a look on ->lock, but it is a bit
vague on which exact entries in rproc it is protecting. 
Before [1] is fixed, this patch might be dropped.

Thanks
Peng

[1]https://lore.kernel.org/linux-remoteproc/6460478.iFIW2sfyFC@nailgun/T/#u