lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ