On Tue, 2009-09-08 at 18:43 -0400, Chuck Lever wrote: > On Sep 8, 2009, at 6:32 PM, Trond Myklebust wrote: > > On Tue, 2009-09-08 at 18:05 -0400, Chuck Lever wrote: > >> Don't dive into memory reclaim in the NFS direct I/O paths, otherwise > >> we can deadlock. > >> > >> Reported by: Wengang Wang <wen.gang.wang@xxxxxxxxxx> > >> Fix-suggested-by: Zach Brown <zach.brown@xxxxxxxxxx> > >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > > > > Wait... What??? How does an O_DIRECT read or write allocation deadlock > > with memory reclaim? Both the read and the write path call > > nfs_direct_req_alloc() before they pin any user pages in memory. > > This may be an issue only for loopback mounts where the backing device > is an NFS O_DIRECT file. This type of deadlock may not be able to > happen in upstream kernels at this point. I don't see how that makes any difference whatsoever. If the backing device is a non-O_DIRECT file, then you have GFP_KERNEL allocation of the pages. Anything that calls down into a filesystem on a read() or write() path had better not assume that it won't block. > Even so, it makes sense for this allocation to be consistent with > similar allocations in the other NFS I/O paths. I don't buy the 'symmetry' argument. The reason for the GFP_NOFS in the nfs_writedata_alloc() is that you have a deadlock when the VM calls ->writepages() in order to reclaim memory. That is not the case here, and so this is not a symmetrical case. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
