From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Gladyshev Ilya <foxido@foxido.dev>, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 7/8] btrfs: simplify return path via cleanup.h
Date: Thu, 13 Nov 2025 09:54:03 +0100 [thread overview]
Message-ID: <20251113085403.GI13846@twin.jikos.cz> (raw)
In-Reply-To: <0a31cf84-ccfe-4da4-b922-85da570c6e3b@gmx.com>
On Thu, Nov 13, 2025 at 07:20:01AM +1030, Qu Wenruo wrote:
> > --- a/fs/btrfs/extent-tree.c
> > +++ b/fs/btrfs/extent-tree.c
> > @@ -1878,16 +1878,14 @@ static int cleanup_ref_head(struct btrfs_trans_handle *trans,
> > * and then re-check to make sure nobody got added.
> > */
> > spin_unlock(&head->lock);
> > - spin_lock(&delayed_refs->lock);
> > - spin_lock(&head->lock);
> > - if (!RB_EMPTY_ROOT(&head->ref_tree.rb_root) || head->extent_op) {
> > - spin_unlock(&head->lock);
> > - spin_unlock(&delayed_refs->lock);
> > - return 1;
> > + {
>
> There are some internal discussion about such anonymous code block usage.
>
> Although I support such usage, especially when it can reduce the
> lifespan of local variables, it's not a commonly accepted pattern yet.
And the discussion is going great, I think we wont't find a consensus
without somebody either missing a coding pattern (you) or suffering to
look at such code each time (me). Others have similar mixed feelings
about the guards use.
next prev parent reply other threads:[~2025-11-13 8:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 18:49 [RFC PATCH 0/8] use cleanup.h in btrfs Gladyshev Ilya
2025-11-12 18:49 ` [RFC PATCH 1/8] btrfs: remove redundant label in __del_qgroup_relation Gladyshev Ilya
2025-11-12 18:49 ` [RFC PATCH 2/8] btrfs: move kfree out of btrfs_create_qgroup's cleanup path Gladyshev Ilya
2025-11-12 20:30 ` Qu Wenruo
2025-11-12 18:49 ` [RFC PATCH 3/8] btrfs: simplify control flow in scrub_simple_mirror Gladyshev Ilya
2025-11-12 18:49 ` [RFC PATCH 4/8] btrfs: simplify function protections with guards Gladyshev Ilya
2025-11-13 8:43 ` David Sterba
2025-11-13 10:06 ` Gladyshev Ilya
2025-11-13 11:25 ` David Sterba
2025-11-13 12:30 ` Daniel Vacek
2025-11-12 18:49 ` [RFC PATCH 5/8] btrfs: use cleanup.h guard()s to simplify unlocks on return Gladyshev Ilya
2025-11-12 18:49 ` [RFC PATCH 6/8] btrfs: simplify cleanup via scoped_guard() Gladyshev Ilya
2025-11-13 8:48 ` David Sterba
2025-11-12 18:49 ` [RFC PATCH 7/8] btrfs: simplify return path via cleanup.h Gladyshev Ilya
2025-11-12 20:50 ` Qu Wenruo
2025-11-13 8:54 ` David Sterba [this message]
2025-11-13 12:48 ` Daniel Vacek
2025-11-12 18:49 ` [RFC PATCH 8/8] btrfs: simplify cleanup in btrfs_add_qgroup_relation Gladyshev Ilya
2025-11-12 20:46 ` Qu Wenruo
2025-11-12 20:55 ` [RFC PATCH 0/8] use cleanup.h in btrfs Qu Wenruo
2025-11-13 8:01 ` Gladyshev Ilya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251113085403.GI13846@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=foxido@foxido.dev \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox