On Sun, Feb 05, 2017 at 01:51:49AM +0000, Al Viro wrote:
> IDGI. Your request is marked aborted and should presumably fail, so
> that when request_wait_answer() wakes up and finds it screwed, fuse_readpage()
> would just return an error and filemap_fault() will return VM_FAULT_SIGBUS,
> with page left not uptodate and _not_ inserted into page tables. What's
> leaking where?
Egads... Do you mean that req->pages[] contents can be dropped by connection
abort right under fuse_copy_pages()? Or is it that args[...].value can
end up freed under you?
<goes to look at the ->end() callbacks>
Both, apparently, plus the request initiator might have seen that
request has failed and buggered off, with args[...].value pointing to
what used to be initiator's stack frame. Is that what you are talking about?
If so, why not mark request as "being handled by fuse_dev_do_{read,write}()"
for the duration, and leave the request_end() on such requests for
fuse_dev_do_{read,write}(), seeing that they will call request_end() for such
anyway?
Looks like your FR_LOCKED is not far from that already. Why not stop
dropping/regaining FR_LOCKED in lock_request()/unlock_request() and simply
have your
end_requests(fc, &to_end2);
in fuse_abort_conn() skip the actual calls of request_end()?
