> On Sep 16, 2016, at 16:27, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > We may end up in here with a FL_FLOCK lock request. We translate those > to whole-file NFSv4 locks and send them on to the server, so we need to > verify that the server supports them no matter what sort of lock request > this is. > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > --- > fs/nfs/nfs4proc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c > index 9d38366666f4..a0f25185c78c 100644 > --- a/fs/nfs/nfs4proc.c > +++ b/fs/nfs/nfs4proc.c > @@ -6135,8 +6135,7 @@ static int _nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lock > unsigned char fl_flags = request->fl_flags; > int status = -ENOLCK; > > - if ((fl_flags & FL_POSIX) && > - !test_bit(NFS_STATE_POSIX_LOCKS, &state->flags)) > + if (!test_bit(NFS_STATE_POSIX_LOCKS, &state->flags)) > goto out; > /* Is this a delegated open? */ > status = nfs4_set_lock_state(state, request); > -- > 2.7.4 The ability to support FL_FLOCK locks does not depend on the server’s support for POSIX locking semantics. FL_FLOCK can also use stacked lock semantics, precisely because they always cover the whole file. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
