Re: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

[Jeff Layton <jlayton@kernel.org>]

On Fri, 2026-03-13 at 09:39 +1100, NeilBrown wrote:
> On Thu, 12 Mar 2026, Jeff Layton wrote:
> > On Fri, 2026-02-27 at 10:54 +0100, Thorsten Leemhuis wrote:
> > > > This was discovered on the Debian openQA infrastructure server when 
> > > > upgrading kernel from v6.12.48 to later v6.12.y where worker hosts (with 
> > > > any earlier or later kernel version) pass NFSv3 mounted ISO images to 
> > > > qemu-system-x86_64 and it reports:
> > > > 
> > > > !!! : qemu-system-x86_64: -device 
> > > > scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0: Failed to get 
> > > > "consistent read" lock: No locks available
> > > > QEMU: Is another process using the image 
> > > > [/var/lib/openqa/pool/2/20260223-1-debian-testing-amd64-netinst.iso]?
> > > > 
> > 
> > I have to wonder if this is a QEMU bug too:
> > 
> > Why is it opening a file read-only and then taking out an exclusive
> > lock on it? What's the point of denying access to other readers?
> 
> It turns out that I mis-diagnosed the problem.  i.e. I guess wrong as to
> what weird thing qemu is doing.
> 
> qemu isn't using flock().  It is using fcntl() locking but at this point
> isn't trying to GET a lock, it is testing if a lock already exists.
> i.e. F_GETLK or F_OFD_GETLK.
> 
> F_GETLK doesn't require WRITE access, even when getting an exclusive
> lock.
> But NFSD does :-)
> 
> So maybe this is the fix that we want.
> 
> diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
> index 255a847ca0b6..67234686ef8c 100644
> --- a/fs/lockd/svclock.c
> +++ b/fs/lockd/svclock.c
> @@ -632,7 +632,7 @@ nlmsvc_testlock(struct svc_rqst *rqstp, struct nlm_file *file,
>  		goto out;
>  	}
>  
> -	mode = lock_to_openmode(&lock->fl);
> +	mode = O_RDONLY;
>  	locks_init_lock(&conflock->fl);
>  	/* vfs_test_lock only uses start, end, and owner, but tests flc_file */
>  	conflock->fl.c.flc_file = lock->fl.c.flc_file;
> 
> 
> 
> ????
> NeilBrown

Oh! That makes much more sense.

We definitely allow F_GETLK requests on local files when the task
doesn't have write access to the file, so I don't see any issue with
allowing it here. Your fix seems sensible to me.

Looking back, it looks like this may have been broken back in 2021 in:

    7f024fcd5c97 ("Keep read and write fds with each nlm_file")

?

Cheers,
-- 
Jeff Layton <jlayton@kernel.org>