[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250409183022.GG13292@suse.cz>
Date: Wed, 9 Apr 2025 20:30:22 +0200
From: David Sterba <dsterba@...e.cz>
To: Yangtao Li <frank.li@...o.com>
Cc: clm@...com, josef@...icpanda.com, dsterba@...e.com,
linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] btrfs: convert to spinlock guards in
btrfs_update_ioctl_balance_args()
On Wed, Apr 09, 2025 at 06:57:22AM -0600, Yangtao Li wrote:
> To simplify handling, use the guard helper to let the compiler care for
> unlocking.
>
> Signed-off-by: Yangtao Li <frank.li@...o.com>
> ---
> fs/btrfs/ioctl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 63aeacc54945..7cec105a4cb0 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -3438,9 +3438,8 @@ void btrfs_update_ioctl_balance_args(struct btrfs_fs_info *fs_info,
> memcpy(&bargs->meta, &bctl->meta, sizeof(bargs->meta));
> memcpy(&bargs->sys, &bctl->sys, sizeof(bargs->sys));
>
> - spin_lock(&fs_info->balance_lock);
> + guard(spinlock)(&fs_info->balance_lock);
Please don't do the guard() conversions in fs/btrfs/, the explicit
locking is the preferred style. If other subsystems use the scoped
locking guards then let them do it.
I personally hate it as it totally disrupts the perception of visibly
demarcated critical sections. I don't see the benefit comparing saved
lines of code vs clear and understandable code.
We rarely have a clear case for the guards, I found a few where it
could be used but then this means we have 2 styles of locking, yet
another code pattern to learn.
Powered by blists - more mailing lists