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
