Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1e2722cee7cc03f0da0623a7d45b9531973c0906.camel@kernel.org>
Subject: Re: [PATCH 3/4] lockd: fix file selection in nlmsvc_cancel_blocked
From:   Jeff Layton <jlayton@kernel.org>
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Trond Myklebust <trond.myklebust@hammerspace.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Date:   Mon, 14 Nov 2022 13:38:05 -0500
In-Reply-To: <55593a438387aca9187a8a8ea1e0d3c2cc4efb9b.camel@kernel.org>
References: <20221111193639.346992-1-jlayton@kernel.org>
         <20221111193639.346992-4-jlayton@kernel.org>
         <1AE4E7CF-F76B-42E8-90D7-5DA52AFDE66E@oracle.com>
         <55593a438387aca9187a8a8ea1e0d3c2cc4efb9b.camel@kernel.org>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2022-11-11 at 16:52 -0500, Jeff Layton wrote:
> On Fri, 2022-11-11 at 20:29 +0000, Chuck Lever III wrote:
> >=20
> > > On Nov 11, 2022, at 2:36 PM, Jeff Layton <jlayton@kernel.org> wrote:
> > >=20
> > > We currently do a lock_to_openmode call based on the arguments from t=
he
> > > NLM_UNLOCK call, but that will always set the fl_type of the lock to
> > > F_UNLCK, the the O_RDONLY descriptor is always chosen.
> >=20
> > Except for the above sentence, these all look sane to me.
> > I can apply them to nfsd's for-next once they've seen some
> > review on fsdevel, as you mentioned in the other thread.
> >=20
> >=20
>=20
> Thanks. That should say "and the O_RDONLY...". Fixed in my tree.
>=20
> I'll go ahead and resend with fsdevel included.
>=20

I reposted the series Friday afternoon.

What might be best is for you to carry the first 3 patches in the nfsd
tree, and I'll take the filelock: patch into the locks-next branch,
along with the other filelock API cleanups.

Sound OK?

> > > Fix it to use the file_lock from the block instead.
> > >=20
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > fs/lockd/svclock.c | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >=20
> > > diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
> > > index 9eae99e08e69..4e30f3c50970 100644
> > > --- a/fs/lockd/svclock.c
> > > +++ b/fs/lockd/svclock.c
> > > @@ -699,9 +699,10 @@ nlmsvc_cancel_blocked(struct net *net, struct nl=
m_file *file, struct nlm_lock *l
> > > 	block =3D nlmsvc_lookup_block(file, lock);
> > > 	mutex_unlock(&file->f_mutex);
> > > 	if (block !=3D NULL) {
> > > -		mode =3D lock_to_openmode(&lock->fl);
> > > -		vfs_cancel_lock(block->b_file->f_file[mode],
> > > -				&block->b_call->a_args.lock.fl);
> > > +		struct file_lock *fl =3D &block->b_call->a_args.lock.fl;
> > > +
> > > +		mode =3D lock_to_openmode(fl);
> > > +		vfs_cancel_lock(block->b_file->f_file[mode], fl);
> > > 		status =3D nlmsvc_unlink_block(block);
> > > 		nlmsvc_release_block(block);
> > > 	}
> > > --=20
> > > 2.38.1
> > >=20
> >=20
> > --
> > Chuck Lever
> >=20
> >=20
> >=20
>=20

--=20
Jeff Layton <jlayton@kernel.org>