On Wed, 29 Nov 2023, Jeff Layton wrote: > > This is another place where we might want to reserve a "rescuer" thread > that avoids doing work that can end up blocked. Maybe we could switch > back to queuing them to the list when we're below a certain threshold of > available threads (1? 2? 4?). A rescuer isn't for cases where work might be blocked, but for cases whether otherwise work might be deadlocked - though maybe that is what you meant. Could nfsd calling filp_close() or __fput() ever deadlock? I think we know from the experience pre v5.8 that calling filp_close() doesn't cause deadlocks. Could __fput, and particularly ->release ever deadlock w.r.t nfsd? i.e. could a ->release function for a file exported through NFS ever wait for nfsd to handle an NFS request? We don't need to worry about indirect dependencies like allocating memory and waiting for nfsd to flush out writes - that is already handled so that we can support loop-back mounts. So to have a problem we would need to nfs-export an NFS filesystem that was being served by the local NFS server. Now that we support NFS re-export, and we support loop-back mounts, it is fair to ask if we support the combination of the two. If we did, then calling ->release from the nfsd thread could deadlock. But calling ->read and ->write (or whatever those interfaces are called today) would also deadlock. So I think we have to say that nfs-reexporting a loop-back NFS mount is not supported, and not supportable. Whether we should try to detect and reject this case is an interesting question, but quite a separate question from that of how to handle the closing of files. In short - I don't think there is any need or value in a dedicated "rescuer" thread here. Thanks, NeilBrown
