[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d73231c675b6d77ca42d8f7a0a866c82c3be821.camel@kernel.org>
Date: Wed, 12 Nov 2025 06:49:21 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>, brauner@...nel.org
Cc: viro@...iv.linux.org.uk, jack@...e.cz, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] filelock: use a consume fence in
locks_inode_context()
On Wed, 2025-11-12 at 11:44 +0100, Mateusz Guzik wrote:
> Matches the idiom of storing a pointer with a release fence and safely
> getting the content with a consume fence after.
>
> Eliminates an actual fence on some archs.
>
> Signed-off-by: Mateusz Guzik <mjguzik@...il.com>
> ---
> include/linux/filelock.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/filelock.h b/include/linux/filelock.h
> index c2ce8ba05d06..37e1b33bd267 100644
> --- a/include/linux/filelock.h
> +++ b/include/linux/filelock.h
> @@ -232,7 +232,10 @@ bool locks_owner_has_blockers(struct file_lock_context *flctx,
> static inline struct file_lock_context *
> locks_inode_context(const struct inode *inode)
> {
> - return smp_load_acquire(&inode->i_flctx);
> + /*
> + * Paired with the fence in locks_get_lock_context().
> + */
> + return READ_ONCE(inode->i_flctx);
> }
>
> #else /* !CONFIG_FILE_LOCKING */
Seems reasonable
Reviewed-by: Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists