Hi,I chosen the code that match with "*unlock*:" label.
On Mon, Jun 23, 2025 at 07:25:41PM +0800, Su Hui wrote:
Using guard() to replace *unlock* label. guard() is better than gotoHow were these cases chosen?
unlock patterns and is more concise. No functional changes.
Signed-off-by: Su Hui <suhui@xxxxxxxxxxxx>
Yes, as Dan mentioned[1], there are too many these patterns and I'm not sure how
I notice that this patch only handles some straightforward mutex_unlock()
cases. There are other opportunities in some places -- particularly
alloc/free patterns.
Overall, I'm not totally convinced that backporting the guard()Got it, it's ok to omit this patch. It seems this patch has not enough value.
infrastructure into code that wasn't originally written to use it is
always worthwhile.
If the code is simple, there is not much benefit. Otherwise, there is
a significant chance of unintentionally changing the behaviour of the
code (though the exercise may be useful if it identifies actual bugs).
Either way, such changes will get in the way of people who are rebasing
on top of this code.
FWIW, this patch looks OK though, and the diffstat looks reasonable.Maybe only for some complex lock/unlock code, guard() can bring some value.
Since this code was recently moved into fs/, diff context noise may be
less of a concern.