Re: git: 8ef0c11e7ce7 - main - nfsclient: upgrade vnode lock in VOP_OPEN()/VOP_CLOSE() if we need to flush buffers
- Reply: Konstantin Belousov : "Re: git: 8ef0c11e7ce7 - main - nfsclient: upgrade vnode lock in VOP_OPEN()/VOP_CLOSE() if we need to flush buffers"
- In reply to: Konstantin Belousov : "git: 8ef0c11e7ce7 - main - nfsclient: upgrade vnode lock in VOP_OPEN()/VOP_CLOSE() if we need to flush buffers"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 23 Nov 2021 08:09:08 UTC
On 2021-Nov-16 17:14:55 +0000, Konstantin Belousov <kib@FreeBSD.org> wrote: > nfsclient: upgrade vnode lock in VOP_OPEN()/VOP_CLOSE() if we need to flush buffers > > VOP_FSYNC() asserts that the vnode is exclusively locked for NFS. > If we try to execute file with recently modified content, the assert is > triggered. I have a diskless arm64 system configured with swap over NFS and I'm now consistently getting a panic during shutdown. I haven't specificially confirmed that it's this commit but the content is suggestive. panic: upgrade of unlocked lock (lockmgr) nfs @ /usr/src/sys/fs/nfsclient/nfs_clvnops.c:855 cpuid = 3 time = 1637166551 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x178 panic() at panic+0x44 witness_upgrade() at witness_upgrade+0x104 lockmgr_upgrade() at lockmgr_upgrade+0x164 nfs_lock() at nfs_lock+0x2c vop_sigdefer() at vop_sigdefer+0x30 _vn_lock() at _vn_lock+0x54 nfs_close() at nfs_close+0xc8 vop_sigdefer() at vop_sigdefer+0x30 VOP_CLOSE_APV() at VOP_CLOSE_APV+0x2c swapdev_close() at swapdev_close+0x3c swapoff_one() at swapoff_one+0x598 sys_swapoff() at sys_swapoff+0x12c do_el0_sync() at do_el0_sync+0x498 handle_el0_sync() at handle_el0_sync+0x90 --- exception, esr 0x56000000 I presume this isn't intended. Can you suggest where I should start looking for the problem? -- Peter Jeremy