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 <[email protected]>
