On Thu, Jun 16 2022, Visa Hankala <v...@hankala.org> wrote: > nfs_inactive() has a lock order reversal. When it removes the silly > file, it locks the directory vnode while it already holds the lock > of the argument file vnode. This clashes for example with name lookups > where directory vnodes are locked before file vnodes. > > The reversal can cause a deadlock when an NFS client has multiple > processes that create, modify and remove files in the same > NFS directory. > > The following patch makes the silly file removal happen after > nfs_inactive() has released the file vnode lock. This should be safe > because the silly file removal is independent of nfs_inactive()'s > argument vnode. > > Could some NFS users test this?
I'm running this diff on the riscv64 build cluster, since 1h25mn with no hang. Let's see how it goes. This cluster doesn't use NFS as much as it could (build logs stored locally) but I can try that in the next build. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
