From: Daniel Vacek <neelx@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH RFC 5/8] ext4: use super write guard in write_mmp_block()
Date: Thu, 6 Nov 2025 11:04:22 +0100 [thread overview]
Message-ID: <CAPjX3FdKdV5ouW3Vjx1jMO8Ye_21x5CDtpOn+BBD_tou1gPkSg@mail.gmail.com> (raw)
In-Reply-To: <5puaizn2a4dpoinvkct2nz5zdvvv5vdrlrmwcz7j6vl7qrxicb@b4qi4yfk4a5u>
On Thu, 6 Nov 2025 at 10:24, Jan Kara <jack@suse.cz> wrote:
>
> On Wed 05-11-25 19:33:35, Daniel Vacek wrote:
> > On Tue, 4 Nov 2025 at 13:16, Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > > ---
> > > fs/ext4/mmp.c | 8 ++------
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/fs/ext4/mmp.c b/fs/ext4/mmp.c
> > > index ab1ff51302fb..6f57c181ff77 100644
> > > --- a/fs/ext4/mmp.c
> > > +++ b/fs/ext4/mmp.c
> > > @@ -57,16 +57,12 @@ static int write_mmp_block_thawed(struct super_block *sb,
> > >
> > > static int write_mmp_block(struct super_block *sb, struct buffer_head *bh)
> > > {
> > > - int err;
> > > -
> > > /*
> > > * We protect against freezing so that we don't create dirty buffers
> > > * on frozen filesystem.
> > > */
> > > - sb_start_write(sb);
> > > - err = write_mmp_block_thawed(sb, bh);
> > > - sb_end_write(sb);
> > > - return err;
> > > + scoped_guard(super_write, sb)
> > > + return write_mmp_block_thawed(sb, bh);
> >
> > Why the scoped_guard here? Should the simple guard(super_write)(sb) be
> > just as fine here?
>
> Not sure about Ted but I prefer scoped_guard() to plain guard() because the
> scoping makes it more visually obvious where the unlocking happens. Of
> course there has to be a balance as the indentation level can go through
> the roof but that's not the case here...
In a general case I completely agree. Though here you can see the end
of the block right on the next line so it looks quite obvious to me
how far the guarded region spans.
But the question is whether to use the guards at all. To me it's a
huge change in reading and understanding the code as more things are
implied and not explicit. Such implied things result in additional
cognitive load. I guess we can handle it eventually. Yet we can fail
from time to time and it is likely we will, at least in the beginning.
Well, my point is this is a new style we're not used to, yet. It just
takes time to adapt. (And usually a few failures to do so.)
--nX
> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
next prev parent reply other threads:[~2025-11-06 10:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 12:12 [PATCH RFC 0/8] fs: introduce super write guard Christian Brauner
2025-11-04 12:12 ` [PATCH RFC 1/8] fs: add super_write_guard Christian Brauner
2025-11-04 12:32 ` Jan Kara
2025-11-04 12:12 ` [PATCH RFC 2/8] btrfs: use super write guard in btrfs_reclaim_bgs_work() Christian Brauner
2025-11-04 20:42 ` Qu Wenruo
2025-11-05 16:33 ` Daniel Vacek
2025-11-04 12:12 ` [PATCH RFC 3/8] btrfs: use super write guard btrfs_run_defrag_inode() Christian Brauner
2025-11-05 16:38 ` Daniel Vacek
2025-11-06 8:19 ` David Sterba
2025-11-04 12:12 ` [PATCH RFC 4/8] btrfs: use super write guard in sb_start_write() Christian Brauner
2025-11-04 17:00 ` Mateusz Guzik
2025-11-04 20:56 ` Christian Brauner
2025-11-04 12:12 ` [PATCH RFC 5/8] ext4: use super write guard in write_mmp_block() Christian Brauner
2025-11-04 12:32 ` Jan Kara
2025-11-04 13:06 ` Theodore Ts'o
2025-11-05 18:33 ` Daniel Vacek
2025-11-06 9:24 ` Jan Kara
2025-11-06 10:04 ` Daniel Vacek [this message]
2025-11-04 12:12 ` [PATCH RFC 6/8] btrfs: use super write guard in relocating_repair_kthread() Christian Brauner
2025-11-04 12:12 ` [PATCH RFC 7/8] open: use super write guard in do_ftruncate() Christian Brauner
2025-11-04 12:32 ` Jan Kara
2025-11-05 18:37 ` Daniel Vacek
2025-11-04 12:12 ` [PATCH RFC 8/8] xfs: use super write guard in xfs_file_ioctl() Christian Brauner
2025-11-04 17:08 ` Darrick J. Wong
2025-11-04 20:57 ` Christian Brauner
2025-11-05 17:47 ` Darrick J. Wong
2025-11-05 18:40 ` Daniel Vacek
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=CAPjX3FdKdV5ouW3Vjx1jMO8Ye_21x5CDtpOn+BBD_tou1gPkSg@mail.gmail.com \
--to=neelx@suse.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).