Thread (7 messages) 7 messages, 5 authors, 2024-09-30

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

From: Philipp Zabel <p.zabel@pengutronix.de>
Date: 2024-09-30 15:22:37
Also in: lkml

On So, 2024-09-29 at 20:48 +0200, Krzysztof Kozlowski wrote:
On 29/09/2024 00:27, Al Viro wrote:
quoted
On Fri, Sep 27, 2024 at 04:02:32PM +0200, Philipp Zabel wrote:
quoted
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.

[...]
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help