On Mon, Feb 06, 2017 at 03:18:42PM +0100, Miklos Szeredi wrote: > But I think it's breakable in the same way: if the deadlocked request > is aborted, the fault will release the page lock as well as mmap_sem, > and from there things will resolve themselves. Right you are - original holder of ->mmap_sem is waiting for request and abort will wake it up... > But you are definitely right about needing to clean up that mess in > fuse/dev.c and doing so by fixing up the arg refcounting for just the > read and write requests is going to be a lot simpler than having to do > that for all of them (which was my original plan). Speaking of refcounting - what's going on with fuse_file one? My reading of that code is that you have 4 states of that thing: * new (just created, fallback request allocated, use fuse_file_free() to kill). Refcount is 0. * intermediate - in fact it's already opened, but still not put into ->private_data. Refcount is still 0. Use fuse_sync_release() to kill. * live - normal refcounting (fuse_file_get()/fuse_file_put()). * shutdown - refcount has reached 0. Can't happen until ->release() (obviously - ->private_data holds a counting reference), some pieces of fuse_sync_release() correspond to some stuff in fuse_release_common(), some - to final fuse_file_put(). To make it even more convoluted, cuse is using fuse_sync_release() and apparently relies upon no references being grabbed after fuse_do_open(), so that thing can be called with refcount 0 *or* refcount 1. Another thing: what guarantees that places in writepages-related paths where we store a reference into req->ff won't hit a request with already non-NULL ->ff? -- 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
