Hi!
----
I'm getting the following errors from nfsd in the kernel log on a regular basis:
---- snip ----
[349278.877256] nfsd: inode locked twice during operation.
[349279.599457] nfsd: inode locked twice during operation.
[349280.302697] nfsd: inode locked twice during operation.
[349280.803115] nfsd: inode locked twice during operation.
---- snip ----
nfsd runs on "Linux 5.10.0-22-rt-686-pae #1 SMP PREEMPT_RT Debian
5.10.178-3 (2023-04-22) i686 GNU/Linux", exported filesystem is btrfs
on a SSD.
NFSv4.1 client is the Windows ms-nfs41-client (git
#e67a792c4249600164852cfc470ac0acdb9f043b) compiling gcc under Cygwin
3.5.0.
Is the nfsd issue known, and if "yes" is there a patch ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
On Sun, Feb 18, 2024 at 01:00:33PM +0100, Roland Mainz wrote:
> Hi!
>
> ----
>
> I'm getting the following errors from nfsd in the kernel log on a regular basis:
> ---- snip ----
> [349278.877256] nfsd: inode locked twice during operation.
> [349279.599457] nfsd: inode locked twice during operation.
> [349280.302697] nfsd: inode locked twice during operation.
> [349280.803115] nfsd: inode locked twice during operation.
> ---- snip ----
>
> nfsd runs on "Linux 5.10.0-22-rt-686-pae #1 SMP PREEMPT_RT Debian
> 5.10.178-3 (2023-04-22) i686 GNU/Linux", exported filesystem is btrfs
> on a SSD.
> NFSv4.1 client is the Windows ms-nfs41-client (git
> #e67a792c4249600164852cfc470ac0acdb9f043b) compiling gcc under Cygwin
> 3.5.0.
>
> Is the nfsd issue known, and if "yes" is there a patch ?
I believe that warning message vanishes as a side-effect of this
series of commits:
7fe2a71dda34 NFSD: introduce struct nfsd_attrs
93adc1e391a7 NFSD: set attributes when creating symlinks
d6a97d3f589a NFSD: add security label to struct nfsd_attrs
c0cbe70742f4 NFSD: add posix ACLs to struct nfsd_attrs
927bfc5600cd NFSD: change nfsd_create()/nfsd_symlink() to unlock directory before returning.
b677c0c63a13 NFSD: always drop directory lock in nfsd_unlink()
e18bcb33bc5b NFSD: only call fh_unlock() once in nfsd_link()
19d008b46941 NFSD: reduce locking in nfsd_lookup()
debf16f0c671 NFSD: use explicit lock/unlock for directory ops
bb4d53d66e4b NFSD: use (un)lock_inode instead of fh_(un)lock for file operations
dd8dd403d7b2 NFSD: discard fh_locked flag and fh_lock/fh_unlock
plus this fix:
00801cd92d91 NFSD: fix regression with setting ACLs.
Any upstream Linux kernel after v6.0 should operate without that
warning. I don't see those commits in origin/linux-5.10.y.
--
Chuck Lever
On Sun, Feb 18, 2024 at 5:45 PM Chuck Lever <[email protected]> wrote:
> On Sun, Feb 18, 2024 at 01:00:33PM +0100, Roland Mainz wrote:
> > I'm getting the following errors from nfsd in the kernel log on a regular basis:
> > ---- snip ----
> > [349278.877256] nfsd: inode locked twice during operation.
> > [349279.599457] nfsd: inode locked twice during operation.
> > [349280.302697] nfsd: inode locked twice during operation.
> > [349280.803115] nfsd: inode locked twice during operation.
> > ---- snip ----
> >
> > nfsd runs on "Linux 5.10.0-22-rt-686-pae #1 SMP PREEMPT_RT Debian
> > 5.10.178-3 (2023-04-22) i686 GNU/Linux", exported filesystem is btrfs
> > on a SSD.
> > NFSv4.1 client is the Windows ms-nfs41-client (git
> > #e67a792c4249600164852cfc470ac0acdb9f043b) compiling gcc under Cygwin
> > 3.5.0.
> >
> > Is the nfsd issue known, and if "yes" is there a patch ?
>
> I believe that warning message vanishes as a side-effect of this
> series of commits:
>
> 7fe2a71dda34 NFSD: introduce struct nfsd_attrs
> 93adc1e391a7 NFSD: set attributes when creating symlinks
> d6a97d3f589a NFSD: add security label to struct nfsd_attrs
> c0cbe70742f4 NFSD: add posix ACLs to struct nfsd_attrs
> 927bfc5600cd NFSD: change nfsd_create()/nfsd_symlink() to unlock directory before returning.
> b677c0c63a13 NFSD: always drop directory lock in nfsd_unlink()
> e18bcb33bc5b NFSD: only call fh_unlock() once in nfsd_link()
> 19d008b46941 NFSD: reduce locking in nfsd_lookup()
> debf16f0c671 NFSD: use explicit lock/unlock for directory ops
> bb4d53d66e4b NFSD: use (un)lock_inode instead of fh_(un)lock for file operations
> dd8dd403d7b2 NFSD: discard fh_locked flag and fh_lock/fh_unlock
>
> plus this fix:
>
> 00801cd92d91 NFSD: fix regression with setting ACLs.
Ouch... ;-(
... so the patch at the bottom of
https://patchwork.kernel.org/project/linux-nfs/patch/[email protected]/#8291331
is not sufficient, right ?
> Any upstream Linux kernel after v6.0 should operate without that
> warning. I don't see those commits in origin/linux-5.10.y.
Are the kernels in the Linux 6.6-stable branch "safe" as NFSv4.x for
NFSv4.1 client development ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
On Mon, Feb 19, 2024 at 04:02:15AM +0100, Roland Mainz wrote:
> On Sun, Feb 18, 2024 at 5:45 PM Chuck Lever <[email protected]> wrote:
> > On Sun, Feb 18, 2024 at 01:00:33PM +0100, Roland Mainz wrote:
> > > I'm getting the following errors from nfsd in the kernel log on a regular basis:
> > > ---- snip ----
> > > [349278.877256] nfsd: inode locked twice during operation.
> > > [349279.599457] nfsd: inode locked twice during operation.
> > > [349280.302697] nfsd: inode locked twice during operation.
> > > [349280.803115] nfsd: inode locked twice during operation.
> > > ---- snip ----
> > >
> > > nfsd runs on "Linux 5.10.0-22-rt-686-pae #1 SMP PREEMPT_RT Debian
> > > 5.10.178-3 (2023-04-22) i686 GNU/Linux", exported filesystem is btrfs
> > > on a SSD.
> > > NFSv4.1 client is the Windows ms-nfs41-client (git
> > > #e67a792c4249600164852cfc470ac0acdb9f043b) compiling gcc under Cygwin
> > > 3.5.0.
> > >
> > > Is the nfsd issue known, and if "yes" is there a patch ?
> >
> > I believe that warning message vanishes as a side-effect of this
> > series of commits:
> >
> > 7fe2a71dda34 NFSD: introduce struct nfsd_attrs
> > 93adc1e391a7 NFSD: set attributes when creating symlinks
> > d6a97d3f589a NFSD: add security label to struct nfsd_attrs
> > c0cbe70742f4 NFSD: add posix ACLs to struct nfsd_attrs
> > 927bfc5600cd NFSD: change nfsd_create()/nfsd_symlink() to unlock directory before returning.
> > b677c0c63a13 NFSD: always drop directory lock in nfsd_unlink()
> > e18bcb33bc5b NFSD: only call fh_unlock() once in nfsd_link()
> > 19d008b46941 NFSD: reduce locking in nfsd_lookup()
> > debf16f0c671 NFSD: use explicit lock/unlock for directory ops
> > bb4d53d66e4b NFSD: use (un)lock_inode instead of fh_(un)lock for file operations
> > dd8dd403d7b2 NFSD: discard fh_locked flag and fh_lock/fh_unlock
> >
> > plus this fix:
> >
> > 00801cd92d91 NFSD: fix regression with setting ACLs.
>
> Ouch... ;-(
> ... so the patch at the bottom of
> https://patchwork.kernel.org/project/linux-nfs/patch/[email protected]/#8291331
> is not sufficient, right ?
That one made it into upstream as:
commit 2336745e87a646a3dc9570f082b85df519ee523e
Author: Kinglong Mee <[email protected]>
AuthorDate: Sat Mar 29 10:23:47 2014 +0800
Commit: J. Bruce Fields <[email protected]>
CommitDate: Sun Mar 30 10:47:34 2014 -0400
NFSD: Clear wcc data between compound ops
Testing NFS4.0 by pynfs, I got some messeages as,
"nfsd: inode locked twice during operation."
When one compound RPC contains two or more ops that locks
the filehandle,the second op will cause the message.
As two SETATTR ops, after the first SETATTR, nfsd will not call
fh_put() to release current filehandle, it means filehandle have
unlocked with fh_post_saved = 1.
The second SETATTR find fh_post_saved = 1, and printk the message.
v2: introduce helper fh_clear_wcc().
Signed-off-by: Kinglong Mee <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
So every Linux kernel after v3.15 has it already.
> > Any upstream Linux kernel after v6.0 should operate without that
> > warning. I don't see those commits in origin/linux-5.10.y.
>
> Are the kernels in the Linux 6.6-stable branch "safe" as NFSv4.x for
> NFSv4.1 client development ?
Generally speaking, later releases are better. If you notice a
specific issue, I can respond to that.
--
Chuck Lever