On 3/5/26 00:03, NeilBrown wrote: > On Tue, 24 Feb 2026, Tj wrote: >> Upstream commit 4cc9b9f2bf4dfe13fe573 "nfsd: refine and rename >> NFSD_MAY_LOCK" and >> stable v6.12.54 commit 18744bc56b0ec (re)moves checks from >> fs/nfsd/vfs.c::nfsd_permission(). >> >> This causes NFS clients to see >> >> $ flock -e -w 4 /srv/NAS/test/debian-13.3.0-amd64-netinst.iso sleep 1 >> flock: /srv/NAS/test/debian-13.3.0-amd64-netinst.iso: No locks available >> >> Keeping the check in nfsd_permission() whilst also copying it to >> fs/nfsd/nfsfh.c::__fh_verify() resolves the issue. >> >> 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:
Neil, thx for the explanation. Jeff, do you have any opinion on what Neil suggested (see quote below). But as Neil mentioned, it's a regression, so it must be handled some way. And it looks like this stalled. Given that the commit in that caused this is somewhat old, I wonder: Is that something we expect other people to run into? If yes, I'd say Linus expects us to fix this. And if not: is there something the Debian openQA infra (a) can and (b) is willing to do to work around this regression cleanly (by upgrading Qemu or something like that maybe)? Then we maybe can leave things as they are[1]. Ciao, Thorsten [1] see the hand-holding aspect mention in https://www.kernel.org/doc/html/next/process/handling-regressions.html#on-exceptions-to-the-no-regressions-rule >> !!! : 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]? >> >> A simple reproducer with the server using: >> >> # cat /etc/exports.d/test.exports >> /srv/NAS/test >> fdff::/64(fsid=0,rw,no_root_squash,sync,no_subtree_check,auth_nlm) >> >> and clients using: >> >> # mount -t nfs [fdff::2]:/srv/NAS/test /srv/NAS/test -o >> proto=tcp6,ro,fsc,soft > > Linux has two quite different sorts of locks - flock and fcntl. > flocks lock the whole file, shared or exclusive. > fcntl can lock any byte-range (including the whole file), shared or > exclusive. flock and fcntl locks don't conflict. > > exclusive flock locks only require read access to the file > exclusive fcntl locks require write access to the file. > > The NLM protocol only supports one type of byte-range lock. It is > natural to map fcntl locks onto NLM locks. The early Linux NFS > implementation handled flock locks entirely locally so different clients > didn't conflict. This could be confusing but was widely documented and > understood. > Some years ago Linux NFS was enhanced to handle flock locks like > whole-file fcntl locks. This means that clients with flock locks would > conflict (maybe good) but that flock locks and fcntl locks would now > conflict (maybe bad). > You can still get the old behaviour with "-o local_lock=flock". > > So if you open a file on NFS read-only and attempt an exclusive flock, > that will be sent to the server as a full-range fcntl lock which should > require write access. If the server finds you don't have write access - > you lose. > > It would seems to make sense to tell qemu that the device is read-only. > Then it will hopefully only request a shared lock. Can you try that? > > Note that even before my patch, if the filesystem was exported read-only > or mounted read-only on the server, then exclusive flock locks would > fail. > > I think that the current behaviour is correct, however I do understand > that it is a regression and maybe that justifies incorrect behaviour. > Maybe Jeff, as locking maintainer, would be willing to do something like > > diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c > index dd0214dcb695..6c674fc51bab 100644 > --- a/fs/lockd/svcsubs.c > +++ b/fs/lockd/svcsubs.c > @@ -73,6 +73,14 @@ static inline unsigned int file_hash(struct nfs_fh *f) > > int lock_to_openmode(struct file_lock *lock) > { > + /* > + * flock only requires READ access and to support > + * clients which send flock locks via NLM we > + * report O_RDONLY for full-file locks. > + */ > + if (lock->fl_start == 0 && > + lock->fl_end == NLM4_OFFSET_MAX) > + return O_RDONLY; > return lock_is_write(lock) ? O_WRONLY : O_RDONLY; > } > > > But I wouldn't encourage him to. > > NeilBrown > > >> >> will trigger the error as shown above: >> >> $ flock -e -w 4 /srv/NAS/test/debian-13.3.0-amd64-netinst.iso sleep 1 >> flock: /srv/NAS/test/debian-13.3.0-amd64-netinst.iso: No locks available >> >> A simple test program calling fcntl() with the same arguments QEMU uses >> also fails in the same way. >> >> $ ./nfs3_range_lock_test >> /srv/NAS/test/debian-13.3.0-amd64-netinst.{iso,overlay} >> Opened base file: /srv/NAS/test/debian-13.3.0-amd64-netinst.iso >> Opened overlay file: /srv/NAS/test/debian-13.3.0-amd64-netinst.overlay >> Attempting lock at 4 on /srv/NAS/test/debian-13.3.0-amd64-netinst.iso >> fcntl(fd, F_GETLK, &fl) failed on base: No locks available >> Attempting lock at 8 on /srv/NAS/test/debian-13.3.0-amd64-netinst.overlay >> fcntl(fd, F_GETLK, &fl) failed on overlay: No locks available >> >> >> >> >
