Re: [PATCH RFC 2/8] btrfs: use super write guard in btrfs_reclaim_bgs_work()

Daniel Vacek
2025-11-05T16:33:15Z

On Tue, 4 Nov 2025 at 21:43, Qu Wenruo <wqu@suse.com> wrote:
> 在 2025/11/4 22:42, Christian Brauner 写道:
> > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > ---
> > fs/btrfs/block-group.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
> > index 5322ef2ae015..8284b9435758 100644
> > --- a/fs/btrfs/block-group.c
> > +++ b/fs/btrfs/block-group.c
> > @@ -1850,7 +1850,7 @@ void btrfs_reclaim_bgs_work(struct work_struct *work)
> > if (!btrfs_should_reclaim(fs_info))
> > return;
> >
> > - sb_start_write(fs_info->sb);
> > + guard(super_write)(fs_info->sb);
> >
> > if (!btrfs_exclop_start(fs_info, BTRFS_EXCLOP_BALANCE)) {
> > sb_end_write(fs_info->sb);
>
> This one is still left using the old scheme, and there is another one in
> the mutex_trylock() branch.
>
> I'm wondering how safe is the new scope based auto freeing.
>
> Like when the freeing function is called? Will it break the existing
> freeing/locking sequence in other locations?
>
> For this call site, sb_end_write() is always called last so it's fine.

It needs to be used sensibly. In this case it matches the original semantics.
Well, up to the part where a guard just consumes additional
stack/register storing the sb pointer. That is the price which needs
to be accounted for.

--nX

> Thanks,
> Qu
>
> > @@ -2030,7 +2030,6 @@ void btrfs_reclaim_bgs_work(struct work_struct *work)
> > list_splice_tail(&retry_list, &fs_info->reclaim_bgs);
> > spin_unlock(&fs_info->unused_bgs_lock);
> > btrfs_exclop_finish(fs_info);
> > - sb_end_write(fs_info->sb);
> > }
> >
> > void btrfs_reclaim_bgs(struct btrfs_fs_info *fs_info)
> >
>
>