On Wed, 16 Apr 2014 16:25:20 +1000 Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Wed, Apr 16, 2014 at 02:03:37PM +1000, NeilBrown wrote: > > __d_alloc can be called with i_mutex held, so it is safer to > > use GFP_NOFS. > > > > lockdep reports this can deadlock when loop-back NFS is in use, > > as nfsd may be required to write out for reclaim, and nfsd certainly > > takes i_mutex. > > But not the same i_mutex as is currently held. To me, this seems > like a false positive? If you are holding the i_mutex on an inode, > then you have a reference to the inode and hence memory reclaim > won't ever take the i_mutex on that inode. > > FWIW, this sort of false positive was a long stabding problem for > XFS - we managed to get rid of most of the false positives like this > by ensuring that only the ilock is taken within memory reclaim and > memory reclaim can't be entered while we hold the ilock. > > You can't do that with the i_mutex, though.... > > Cheers, > > Dave. I'm not sure this is a false positive. You can call __d_alloc when creating a file and so are holding i_mutex on the directory. nfsd might also want to access that directory. If there was only 1 nfsd thread, it would need to get i_mutex and do it's thing before replying to that request and so before it could handle the COMMIT which __d_alloc is waiting for. Obviously we would normally have multiple nfsd threads but if they were all blocked on an i_mutex which itself was blocked on nfs_release_page which was waiting for an nfsd thread to handling its COMMIT request, this could be a real deadlock. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
