Re: [PATCH] 9p: don't ignore fatal signals during flush

[Dominique Martinet <asmadeus@codewreck.org>]

Dominique Martinet wrote on Sun, Mar 22, 2026 at 09:09:31PM +0900:
> Unfortunately we pretty much have to wait for the flush to complete for
> consistency in some RPCs (I don't remember what exactly, before commit
> 728356dedeff ("9p: Add refcount to p9_req_t") there was an obvious use
> after free, now there should not be a UAF problem but for some reason
> I've always been waiting for async flush (something like [1], execept it
> introduced other regressions and never made it because of eternal Lack
> Of Time))

Just thinking about it some more, one problem even with refcount would
be that we'll be either leaking memory/the tag for the request (if we
just take the ref on return from p9_client_rpc and wait to receive the
response), or will free the tag and risk reusing it before the server
replies to the original request.

I really don't see how that could work decently without some kind of
async flush.

If you're interested in taking over, I had rebased the 2018 patches I
linked earlier in 2023 here:
https://github.com/martinetd/linux/commits/9p-async-v2

I don't remember why I didn't send it for review again in 2023,
part of the 2019 patches about async clunks definitely was a problem
because we have to wait for the clunk happy path (because some servers
flush on clunk when cache is involved), but the 2023 patches properly
only do it on retry which is a net improvement, and the flush code
should be workable in theory, so this would "just" need another rebase
(that should not be too bad) and heavy testing...

Whatever we'd merge doesn't need to be based on these patches if you
prefer to reimplement it, I'm not concerned about authorship here, but I
don't think the current approach is appropriate.


Thanks,
-- 
Dominique Martinet | Asmadeus