All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
	CIFS <linux-cifs@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>, "hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH 7/7] nfsd: use locks_inode_context helper
Date: Wed, 16 Nov 2022 10:36:22 -0500	[thread overview]
Message-ID: <388754c59ed73360ccd41c5b85ceadea37a75b9e.camel@kernel.org> (raw)
In-Reply-To: <406B1FC6-23B1-429D-B9BD-33EF0DD7C908@oracle.com>

On Wed, 2022-11-16 at 15:21 +0000, Chuck Lever III wrote:
> 
> > On Nov 16, 2022, at 10:17 AM, Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > nfsd currently doesn't access i_flctx safely everywhere. This requires a
> > smp_load_acquire, as the pointer is set via cmpxchg (a release
> > operation).
> > 
> > Cc: Chuck Lever <chuck.lever@oracle.com>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> 
> Acked-by: Chuck Lever <chuck.lever@oracle.com>
> 
> 
> > ---
> > fs/nfsd/nfs4state.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 836bd825ca4a..da8d0ea66229 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -4758,7 +4758,7 @@ nfs4_share_conflict(struct svc_fh *current_fh, unsigned int deny_type)
> > 
> > static bool nfsd4_deleg_present(const struct inode *inode)
> > {
> > -	struct file_lock_context *ctx = smp_load_acquire(&inode->i_flctx);
> > +	struct file_lock_context *ctx = locks_inode_context(inode);
> > 
> > 	return ctx && !list_empty_careful(&ctx->flc_lease);
> > }
> > @@ -5897,7 +5897,7 @@ nfs4_lockowner_has_blockers(struct nfs4_lockowner *lo)
> > 
> > 	list_for_each_entry(stp, &lo->lo_owner.so_stateids, st_perstateowner) {
> > 		nf = stp->st_stid.sc_file;
> > -		ctx = nf->fi_inode->i_flctx;
> > +		ctx = locks_inode_context(nf->fi_inode);

Thanks Chuck.

To be clear: I think the above access is probably OK. We wouldn't have a
lock stateid unless we had a valid lock context in the inode. That said,
doing it this way keeps everything consistent, so I'm inclined to leave
the patch as-is.

check_for_locks definitely needs this though.

> > 		if (!ctx)
> > 			continue;
> > 		if (locks_owner_has_blockers(ctx, lo))
> > @@ -7713,7 +7713,7 @@ check_for_locks(struct nfs4_file *fp, struct nfs4_lockowner *lowner)
> > 	}
> > 
> > 	inode = locks_inode(nf->nf_file);
> > -	flctx = inode->i_flctx;
> > +	flctx = locks_inode_context(inode);
> > 
> > 	if (flctx && !list_empty_careful(&flctx->flc_posix)) {
> > 		spin_lock(&flctx->flc_lock);
> > -- 
> > 2.38.1
> > 
> 
> --
> Chuck Lever
> 
> 
> 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2022-11-16 15:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 15:17 [PATCH 0/7] fs: fix inode->i_flctx accesses Jeff Layton
2022-11-16 15:17 ` [PATCH 1/7] filelock: add a new locks_inode_context accessor function Jeff Layton
2022-11-16 16:08   ` Christoph Hellwig
2022-11-16 17:43     ` Jeff Layton
2022-11-16 15:17 ` [PATCH 2/7] ceph: use locks_inode_context helper Jeff Layton
2022-11-16 16:08   ` Christoph Hellwig
2022-11-17  4:56   ` Xiubo Li
2022-11-16 15:17 ` [PATCH 3/7] cifs: " Jeff Layton
2022-11-16 16:09   ` Christoph Hellwig
2022-11-16 15:17 ` [PATCH 4/7] ksmbd: " Jeff Layton
2022-11-16 16:09   ` Christoph Hellwig
2022-11-16 23:45   ` Namjae Jeon
2022-11-16 15:17 ` [PATCH 5/7] lockd: " Jeff Layton
2022-11-16 16:09   ` Christoph Hellwig
2022-11-16 15:17 ` [PATCH 6/7] nfs: " Jeff Layton
2022-11-16 16:10   ` Christoph Hellwig
2022-11-16 15:17 ` [PATCH 7/7] nfsd: " Jeff Layton
2022-11-16 15:21   ` Chuck Lever III
2022-11-16 15:36     ` Jeff Layton [this message]
2022-11-16 16:10   ` Christoph Hellwig

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=388754c59ed73360ccd41c5b85ceadea37a75b9e.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=hch@lst.de \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.