[lustre-devel] [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call
viro at ZenIV.linux.org.uk
Mon Feb 6 23:19:09 PST 2017
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
More information about the lustre-devel