Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #91366 > unrolled thread

Bug#1128861: linux: when serving NFS, client attempts to lock served files fail with "No locks available"

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1128861: linux: when serving NFS, client attempts to lock served files fail with "No locks available" Philip Hands <phil@hands.com> - 2026-02-23 20:40 +0100
    Bug#1128861: Acknowledgement (linux: when serving NFS, client attempts to lock served files fail with "No locks available") Philip Hands <phil@hands.com> - 2026-02-23 23:30 +0100
    Bug#1128861: Acknowledgement (linux: when serving NFS, client attempts to lock served files fail with "No locks available") Philip Hands <phil@hands.com> - 2026-02-24 00:40 +0100
      Bug#1128861: Acknowledgement (linux: when serving NFS, client attempts to lock served files fail with "No locks available") Philip Hands <phil@hands.com> - 2026-02-24 01:30 +0100
    Bug#1128861: Revert 18744bc56b0ec appears to resolve it Tj <tj.iam.tj@proton.me> - 2026-02-24 01:50 +0100
    Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available Tj <tj.iam.tj@proton.me> - 2026-02-24 03:20 +0100
      Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available Tj <tj.iam.tj@proton.me> - 2026-02-24 14:00 +0100
      Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available Thorsten Leemhuis <regressions@leemhuis.info> - 2026-02-27 11:10 +0100
        Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available Salvatore Bonaccorso <carnil@debian.org> - 2026-03-04 11:40 +0100
      Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available Sasha Levin <sashal@kernel.org> - 2026-03-04 16:50 +0100
    Processed: Re: Bug#1128861: Regression: Missing check in  nfsd_permission() causes -ENOLCK No locks available "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-03-04 11:40 +0100
    Bug#1128861: [PATCH] lockd: fix TEST handling when not all permissions are available. Ben Hutchings <ben@decadent.org.uk> - 2026-03-25 21:40 +0100
    Bug#1128861: [PATCH v2] lockd: fix TEST handling when not all permissions are available. Uwe Kleine-König <ukleinek@debian.org> - 2026-04-01 15:00 +0200
    Bug#1128861: marked as done (linux: when serving NFS, client  attempts to lock served files fail with "No locks available") "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-06-10 12:40 +0200
    Bug#1128861: marked as done (linux: when serving NFS, client  attempts to lock served files fail with "No locks available") "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-07-02 22:30 +0200

#91366 — Bug#1128861: linux: when serving NFS, client attempts to lock served files fail with "No locks available"

Source: linux
Version: 6.12.57-1
Severity: normal

The setup we have on openqa.debian.net and it's openqa-worker machines is that
the workers have a read-only NFS mount of a share containing the .iso images
that are used for booting the test VMs.

All kernels that I have available since 6.12.48 (6.12.57 6.12.69 6.12.73 &
6.18.5) cause the workers to fail when they try to apply a "consistent read"
lock, giving the error message: No locks available

One can demonstrate that by running this on the NFS client:

  $ flock -e -w 4 /var/lib/openqa/factory/iso/xfce_sid_20260223T140607Z.iso sleep 1
  flock: /var/lib/openqa/factory/iso/xfce_sid_20260223T140607Z.iso: No locks available

meanwhile, running that flock on the server works fine.

BTW Here are the journals from booting various versions of the kernel:

  https://hands.com/~phil/tmp/openqa-nfs-lock-issue/

Cheers, Phil.

[toc] | [next] | [standalone]

#91370 — Bug#1128861: Acknowledgement (linux: when serving NFS, client attempts to lock served files fail with "No locks available")

The /etc/exports entry on the server for the share in question is:

  /var/lib/openqa/share *(fsid=0,rw,no_root_squash,sync,no_subtree_check)

and the /etc/fstab entries on the clients (both of which show the behaviour) are:

  openqa.debian.net:/var/lib/openqa/share /var/lib/openqa/share nfs ro,fsc,soft,bg 0 0

and:

  openqa.debian.net:/var/lib/openqa/share /var/lib/openqa/share nfs nofail,ro,fsc,soft,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10s 0 0

[toc] | [prev] | [next] | [standalone]

#91372 — Bug#1128861: Acknowledgement (linux: when serving NFS, client attempts to lock served files fail with "No locks available")

Here's a bisect log:

# bad: [8a243ecde1f6447b8e237f2c1c67c0bb67d16d67] Linux 6.12.57
# good: [f1e375d5eb68f990709fce37ee1c0ecae3645b6f] Linux 6.12.48
git bisect start 'v6.12.57' 'v6.12.48'
# good: [28defa35ed158bcca43e0d3d0122e747f57be867] clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver
git bisect good 28defa35ed158bcca43e0d3d0122e747f57be867
# bad: [3e7b89ed9f07e6864943c4237a9c86e0cf9d3f33] drm/msm/a6xx: Fix PDC sleep sequence
git bisect bad 3e7b89ed9f07e6864943c4237a9c86e0cf9d3f33
# good: [cbcfb32b6aaeebda11c945698634294a48259ac3] memory: samsung: exynos-srom: Fix of_iomap leak in exynos_srom_probe
git bisect good cbcfb32b6aaeebda11c945698634294a48259ac3
# good: [32c258aad47ef9c58c8ae50e160b9c94c43f3829] KVM: x86: Advertise SRSO_USER_KERNEL_NO to userspace
git bisect good 32c258aad47ef9c58c8ae50e160b9c94c43f3829
# bad: [e67e3e738f088e6c5ccfab618a29318a3f08db41] sched/fair: Block delayed tasks on throttled hierarchy during dequeue
git bisect bad e67e3e738f088e6c5ccfab618a29318a3f08db41
# bad: [1e059ce9cc7b20f19d3c4b6e39e72ecb42da1ce8] mptcp: pm: in-kernel: usable client side with C-flag
git bisect bad 1e059ce9cc7b20f19d3c4b6e39e72ecb42da1ce8
# bad: [0a1ee3c932dcf6f446e69a0ce67f36550a69a9ed] nfsd: don't use sv_nrthreads in connection limiting calculations.
git bisect bad 0a1ee3c932dcf6f446e69a0ce67f36550a69a9ed
# good: [34ff466f74d0fe1db8956f9c245e2bb2c67f67bf] x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP
git bisect good 34ff466f74d0fe1db8956f9c245e2bb2c67f67bf
# good: [763d4aa418456afb2e1bdef27216332352813aad] NFSD: Replace use of NFSD_MAY_LOCK in nfsd4_lock()
git bisect good 763d4aa418456afb2e1bdef27216332352813aad
# good: [18744bc56b0ec34b0fe397ee71c2ffdc48c6a0e0] nfsd: refine and rename NFSD_MAY_LOCK
git bisect good 18744bc56b0ec34b0fe397ee71c2ffdc48c6a0e0
# first bad commit: [0a1ee3c932dcf6f446e69a0ce67f36550a69a9ed] nfsd: don't use sv_nrthreads in connection limiting calculations.

[toc] | [prev] | [next] | [standalone]

#91373 — Bug#1128861: Acknowledgement (linux: when serving NFS, client attempts to lock served files fail with "No locks available")

Philip Hands <phil@hands.com> writes:

> Here's a bisect log:
>
...
> # good: [18744bc56b0ec34b0fe397ee71c2ffdc48c6a0e0] nfsd: refine and rename NFSD_MAY_LOCK
> git bisect good 18744bc56b0ec34b0fe397ee71c2ffdc48c6a0e0

It seems that ^ was a mistake on my part -- having retested
18744bc56b0ec34 it is in fact bad.

[toc] | [prev] | [next] | [standalone]

#91374 — Bug#1128861: Revert 18744bc56b0ec appears to resolve it

After several test of the .53...54 NFSD changes I've found that 
reverting 18744bc56b0ec

"nfsd: refine and rename NFSD_MAY_LOCK"

appears to resolve it in my debvm-created server test scenario.

Likewise, a build before those NFSD changes at 34ff466f74d0f also works 
fine.

[toc] | [prev] | [next] | [standalone]

#91376 — Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

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:

!!! : 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

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

[toc] | [prev] | [next] | [standalone]

#91385 — Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

Follow-up with results of adding dump_stack() to nfsd_permission() 
revealing the paths that trigger the issue.

[  133.185579] Call Trace:
[  133.185580]  <TASK>
[  133.185580]  dump_stack_lvl+0x64/0x80
[  133.185582]  nfsd_permission+0x20/0x100 [nfsd]
[  133.185612]  nfsd_access+0xc8/0x140 [nfsd]
[  133.185639]  nfsd4_proc_compound+0x350/0x670 [nfsd]
[  133.185670]  nfsd_dispatch+0x100/0x220 [nfsd]
[  133.185698]  svc_process_common+0x314/0x700 [sunrpc]
[  133.185733]  ? __pfx_nfsd_dispatch+0x10/0x10 [nfsd]
[  133.185762]  svc_process+0x131/0x1c0 [sunrpc]
[  133.185795]  svc_recv+0x80a/0x9e0 [sunrpc]
[  133.185827]  ? __pfx_nfsd+0x10/0x10 [nfsd]
[  133.185856]  nfsd+0xa3/0x100 [nfsd]
[  133.185882]  kthread+0xd2/0x100
[  133.185884]  ? __pfx_kthread+0x10/0x10
[  133.185885]  ret_from_fork+0x34/0x50
[  133.185886]  ? __pfx_kthread+0x10/0x10
[  133.185887]  ret_from_fork_asm+0x1a/0x30
[  133.185890]  </TASK>

[  144.020165] Call Trace:
[  144.020165]  <TASK>
[  144.020166]  dump_stack_lvl+0x64/0x80
[  144.020168]  nfsd_permission+0x20/0x100 [nfsd]
[  144.020201]  nfsd_access+0xc8/0x140 [nfsd]
[  144.020228]  nfsd3_proc_access+0x6c/0x110 [nfsd]
[  144.020257]  nfsd_dispatch+0x100/0x220 [nfsd]
[  144.020286]  svc_process_common+0x314/0x700 [sunrpc]
[  144.020321]  ? __pfx_nfsd_dispatch+0x10/0x10 [nfsd]
[  144.020350]  svc_process+0x131/0x1c0 [sunrpc]
[  144.020383]  svc_recv+0x80a/0x9e0 [sunrpc]
[  144.020415]  ? __pfx_nfsd+0x10/0x10 [nfsd]
[  144.020445]  nfsd+0xa3/0x100 [nfsd]
[  144.020471]  kthread+0xd2/0x100
[  144.020472]  ? __pfx_kthread+0x10/0x10
[  144.020473]  ret_from_fork+0x34/0x50
[  144.020475]  ? __pfx_kthread+0x10/0x10
[  144.020476]  ret_from_fork_asm+0x1a/0x30
[  144.020478]  </TASK>

[toc] | [prev] | [next] | [standalone]

#91452 — Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

[CCing a few people and lists]

On 2/24/26 03:09, Tj wrote:
> Upstream commit 4cc9b9f2bf4dfe13fe573 "nfsd: refine and rename 
> NFSD_MAY_LOCK" and
>   stable v6.12.54 commit 18744bc56b0ec

In case anyone just like me is wondering: the latter is a backport of
the former.

>  (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

Does this happen on mainline (e.g. 7.0-rc1) as well?

Ciao, Thorsten

> 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:
> 
> !!! : 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
> 
> 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
> 
> 

[toc] | [prev] | [next] | [standalone]

#91519 — Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

Control: found -1 6.19.5-1~exp1
Hi,

On Fri, Feb 27, 2026 at 10:54:13AM +0100, Thorsten Leemhuis wrote:
> [CCing a few people and lists]
> 
> On 2/24/26 03:09, Tj wrote:
> > Upstream commit 4cc9b9f2bf4dfe13fe573 "nfsd: refine and rename 
> > NFSD_MAY_LOCK" and
> >   stable v6.12.54 commit 18744bc56b0ec
> 
> In case anyone just like me is wondering: the latter is a backport of
> the former.
> 
> >  (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
> 
> Does this happen on mainline (e.g. 7.0-rc1) as well?

Not tested 7.0-rc2, but the issue is reproducible still in 6.19.5.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#91521 — Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

This response was AI-generated by bug-bot. The analysis may contain errors — please verify independently.

---

Bug Summary

Commit 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK"),
backported to v6.12.54 as 18744bc56b0ec, removed a critical
permission downgrade from nfsd_permission() that affects NLM lock
requests. This is a severity: functional regression -- exclusive
(and shared) file locking via NLM fails with ENOLCK on files where
the requesting user lacks write permission on the inode, such as
read-only ISO images served over NFSv3.

Stack Trace Analysis

No stack trace was included in the report; the failure is a
user-visible ENOLCK error, not a kernel crash or warning.

Root Cause Analysis

The bug is in the interaction between nlm_fopen() in
fs/nfsd/lockd.c and nfsd_permission() in fs/nfsd/vfs.c.

Before 4cc9b9f2bf4d, nfsd_permission() contained this block:

    if (acc & NFSD_MAY_LOCK) {
        if (exp->ex_flags & NFSEXP_NOAUTHNLM)
            return 0;
        else
            acc = NFSD_MAY_READ | NFSD_MAY_OWNER_OVERRIDE;
    }

This downgraded the permission check for lock requests from
MAY_WRITE to MAY_READ, because file locks do not require write
access to the file data -- only read access is needed.

Commit 4cc9b9f2bf4d correctly moved the NFSEXP_NOAUTHNLM bypass
into __fh_verify() (fs/nfsd/nfsfh.c, line 377) and added explicit
NFSD_MAY_OWNER_OVERRIDE and NFSD_MAY_BYPASS_GSS flags in
nlm_fopen(). However, it dropped the permission downgrade (the
"else" branch) entirely.

The call chain for an exclusive NLM lock is:

  nlm_fopen() [fs/nfsd/lockd.c:50]
    access = NFSD_MAY_WRITE | NFSD_MAY_NLM | NFSD_MAY_OWNER_OVERRIDE
             | NFSD_MAY_BYPASS_GSS
  -> nfsd_open()
    -> __fh_verify() -> nfsd_permission()
      -> inode_permission(inode, MAY_WRITE)   <-- FAILS with -EACCES
  -> nfsd_open() returns nfserr
  -> nlm_fopen() default case returns nlm_failed
  -> client sees ENOLCK

For files like ISO images (typically mode 0444 or 0644 owned by
root), the requesting NFS user does not have write permission, so
inode_permission(MAY_WRITE) fails. Previously, the downgrade to
MAY_READ would have allowed this to succeed.

The NFSD_MAY_OWNER_OVERRIDE added in nlm_fopen() only helps when
the NFS credential matches the file owner (checked at
fs/nfsd/vfs.c:2858), which is not the case for files owned by
root when accessed by non-root NFS users.

Affected Versions

This is a regression introduced by:
  4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK")

Mainline: affected since v6.13-rc1
Stable:   v6.12.54+ (backport 18744bc56b0ec)

Any kernel version >= v6.13 or v6.12.54 is affected. Versions
prior to v6.12.54 in the 6.12.y series are not affected.

Relevant Commits and Fixes

Introducing commit (mainline):
  4cc9b9f2bf4d nfsd: refine and rename NFSD_MAY_LOCK

Stable backport:
  18744bc56b0ec nfsd: refine and rename NFSD_MAY_LOCK (v6.12.54)

Predecessor commit that removed NFSD_MAY_LOCK from NFSv4:
  6640556b0c80 NFSD: Replace use of NFSD_MAY_LOCK in nfsd4_lock()

Existing partial fix for a different aspect of the same regression:
  0813c5f01249 nfsd: fix access checking for NLM under XPRTSEC policies
  (Fixes: 4cc9b9f2bf4d, by Olga Kornievskaia -- addresses only the
  XPRTSEC policy bypass, NOT the permission downgrade issue)

No existing mainline fix for the permission downgrade regression
was found.

Prior Discussions

No prior reports of this specific NLM permission downgrade
regression were found on lore.kernel.org. The only related
discussion is the XPRTSEC fix by Olga Kornievskaia (commit
0813c5f01249), which addresses a different facet of the same
4cc9b9f2bf4d refactoring.

The original bug was also reported via Debian bug #1128861.

Adding Neil Brown who authored the original commit 4cc9b9f2bf4d.
Adding Chuck Lever and Jeff Layton as NFSD maintainers.
Adding Olga Kornievskaia who authored the related XPRTSEC fix
(0813c5f01249) and is an NFSD reviewer.
Adding Dai Ngo and Tom Talpey as NFSD reviewers.
CC'ing stable@vger.kernel.org as the regression affects v6.12.y.

Suggested Actions

The fix is to restore the permission downgrade for NFSD_MAY_NLM
in nfsd_permission() (fs/nfsd/vfs.c). The following patch should
resolve the issue:

  --- a/fs/nfsd/vfs.c
  +++ b/fs/nfsd/vfs.c
  @@ nfsd_permission(...)
       if ((acc & NFSD_MAY_TRUNC) && IS_APPEND(inode))
           return nfserr_perm;

  +    if (acc & NFSD_MAY_NLM)
  +        acc = NFSD_MAY_READ | NFSD_MAY_OWNER_OVERRIDE;
  +
       /*
        * The file owner always gets access permission for accesses that

This restores the "else" branch behavior that was lost in
4cc9b9f2bf4d: for NLM lock requests, the inode permission check
is downgraded from MAY_WRITE to MAY_READ, since file locks do not
require write access to the file data.

The reporter's workaround of keeping the check in nfsd_permission()
while also having the copy in __fh_verify() confirms this analysis.

For immediate relief, the reporter can either:
1. Apply the above one-line fix and rebuild the kernel
2. Downgrade to v6.12.48 or earlier in the 6.12.y series

Neil, could you review whether restoring just the permission
downgrade (without the NFSEXP_NOAUTHNLM check, which is now
correctly handled in __fh_verify) is the right approach?

[toc] | [prev] | [next] | [standalone]

#91520 — Processed: Re: Bug#1128861: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

Processing control commands:

> found -1 6.19.5-1~exp1
Bug #1128861 [src:linux] linux: when serving NFS, client attempts to lock served files fail with "No locks available"
Marked as found in versions linux/6.19.5-1~exp1.

-- 
1128861: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#91799 — Bug#1128861: [PATCH] lockd: fix TEST handling when not all permissions are available.

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2026-03-25 at 18:08 +1100, NeilBrown wrote:
> On Wed, 25 Mar 2026, Chuck Lever wrote:
> > 
> > On Tue, Mar 24, 2026, at 6:13 AM, NeilBrown wrote:
> > > From: NeilBrown <neil@brown.name>
> > > 
> > > The F_GETLK fcntl can work with either read access or write access or
> > > both.  It can query F_RDLCK and F_WRLCK locks in either case.
> > > 
> > > However lockd currently treats F_GETLK similar to F_SETLK in that read
> > > access is required to query an F_RDLCK lock and write access is required
> > > to query a F_WRLCK lock.
> > > 
> > > This is wrong and can cause problem - e.g.  when qemu accesses a
> > > read-only (e.g. iso) filesystem image over NFS (though why it queries
> > > if it can get a write lock - I don't know.  But it does, and this works
> > > with local filesystems).
> > > 
> > > So we need TEST requests to be handled differently.  To do this:
> > > 
> > > - change nlm_do_fopen() to accept O_RDWR as a mode and in that case
> > >   succeed if either a O_RDONLY or O_WRONLY file can be opened.
> > > - change nlm_lookup_file() to accept a mode argument from caller,
> > >   instead of deducing base on lock time, and pass that on to nlm_do_fopen()
> > > - change nlm4svc_retrieve_args() and nlmsvc_retrieve_args() to detect
> > >   TEST requests and pass O_RDWR as a mode to nlm_lookup_file, passing
> > >   the same mode as before for other requests.  Also set
> > >    lock->fl.c.flc_file to whichever file is available for TEST requests.
> > > - change nlmsvc_testlock() to also not calculate the mode, but to use
> > >   whenever was stored in lock->fl.c.flc_file.
> > > 
> > > Reported-by: Tj <tj.iam.tj@proton.me>
> > > Link:  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861
> > > Fixes: 7f024fcd5c97 ("Keep read and write fds with each nlm_file")
> > > Signed-off-by: NeilBrown <neil@brown.name>
> > 
> > Hi Neil, which kernels should this fix apply to?
> > 
> 
> v6.13 and later. So linux-6.18.y and linux-6.19.y

6.12.y is also affected since commit 4cc9b9f2bf4d was backported there
(triggering this bug report).

Ben.

> 
> The Fixes: tag is actually wrong.  This bug has been present forever.
> However a different bug that 
>   Commit: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK")
> fixed was hiding the bug.
> 
> So it should probably be marked
>   Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK")
> with an explanation.
> 
> NeilBrown

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine

[toc] | [prev] | [next] | [standalone]

#91878 — Bug#1128861: [PATCH v2] lockd: fix TEST handling when not all permissions are available.

[Multipart message — attachments visible in raw view] — view raw

Hello Chuck,

On Fri, Mar 27, 2026 at 09:56:38AM -0400, Chuck Lever wrote:
> I think the stable folks will insist on this fix going into
> upstream first. However, this version of the fix does not
> apply to nfsd-testing because that branch has the NLMv4
> xdrgen rewrite.

This is not the first time a bug is fixed by changes that are too
intrusive for backport. Usually the stable maintainers can be talked to
accept a small targeted fix even if it's not upstream. The discussion is
simplified by people claiming to have tested the fix and confirm it
helps.

Best regards
Uwe

[toc] | [prev] | [next] | [standalone]

#92942 — Bug#1128861: marked as done (linux: when serving NFS, client attempts to lock served files fail with "No locks available")

[Multipart message — attachments visible in raw view] — view raw

Your message dated Wed, 10 Jun 2026 10:36:57 +0000
with message-id <E1wXGIr-00000008Ory-1y2q@fasolo.debian.org>
and subject line Bug#1128861: fixed in linux 7.1~rc7-1~exp1
has caused the Debian Bug report #1128861,
regarding linux: when serving NFS, client attempts to lock served files fail with "No locks available"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1128861: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#93186 — Bug#1128861: marked as done (linux: when serving NFS, client attempts to lock served files fail with "No locks available")

[Multipart message — attachments visible in raw view] — view raw

Your message dated Thu, 02 Jul 2026 20:24:46 +0000
with message-id <E1wfNxm-00000001lSA-1VoR@fasolo.debian.org>
and subject line Bug#1128861: fixed in linux 7.0.14-1
has caused the Debian Bug report #1128861,
regarding linux: when serving NFS, client attempts to lock served files fail with "No locks available"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1128861: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web