linux-kernel - Re: [heads-up] Re: [PATCH] reset: Further simplify locking with guard()

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: <b4d9fb99dbd2e2a6a6ce39744e2e640d35ea97c7.camel@pengutronix.de>
Date: Mon, 30 Sep 2024 17:22:25 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Al Viro
	 <viro@...iv.linux.org.uk>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
 kernel@...gutronix.de, Linus Torvalds <torvalds@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>
Subject: Re: [heads-up] Re: [PATCH] reset: Further simplify locking with
 guard()

On So, 2024-09-29 at 20:48 +0200, Krzysztof Kozlowski wrote:
> On 29/09/2024 00:27, Al Viro wrote:
> > On Fri, Sep 27, 2024 at 04:02:32PM +0200, Philipp Zabel wrote:
> > > Use guard(mutex) to automatically unlock mutexes when going out of
> > > scope. Simplify error paths by removing a goto and manual mutex
> > > unlocking in multiple places.
> > 
> > And that, folks, is a live example of the reasons why guard() is an
> > attractive nuisance.  We really need a very loud warning on
> > cleanup.h stuff - otherwise such patches from well-meaning folks
> > will keep coming.

Thank you for the analysis. It think I'll drop this entirely.

[...]
> > 
> > Guess what happens if you take goto out_put prior to the entire thing,
> > in
> >                 ret = __reset_add_reset_gpio_device(&args);
> > 		if (ret) {
> > 			rstc = ERR_PTR(ret);
> > 			goto out_put;
> > 		}
> > That patch adds implicit mutex_unlock() at the points where we leave
> > the scope.  Which extends to the end of function.  In other words, there is
> > one downstream of out_put, turning any goto out_put upstream of guard() into
> > a bug.
> > 
> 
> cleanup.h also mentions that one should do not mix cleanup with existing
> goto, because of possibility of above issue.

Yes, d5934e76316e ("cleanup: Add usage and style documentation"), last
paragraph.

> But except careful review, this patch should have been simply compile
> tested which would point to the issue above. Any guard/scope works must
> be checked with clang W=1, which reports jumps over init.

Thank you, I was missing a CC=clang W=1 build in my pre-flight checks.
That's fixed now.

regards
Philipp