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

[Dominique Martinet]

Thanks for the patch,

Shigeru Yoshida wrote on Sun, Mar 22, 2026 at 08:18:47PM +0900:
> When a 9P RPC request is interrupted by a signal, p9_client_rpc() clears
> TIF_SIGPENDING and attempts to flush the pending request by calling
> p9_client_flush(). Since commit 9523feac272c switched the wait from
> wait_event_interruptible() to wait_event_killable(), only SIGKILL can
> interrupt the wait. However, the flush path also clears TIF_SIGPENDING,
> which prevents subsequent wait_event_killable() calls from detecting the
> already-pending SIGKILL. This makes the task unkillable.

Yes, the task is unkillable, it's a known issue -- I don't see how
that's a new problem with the switch to wait_event_killable(), as far as
I'm aware it was a problem even before the commit you listed.

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))

If you've really thought it out and can convince me we can safely do
this I'll give it another thought but in practice it's only a problem
for broken servers (or syzcaller), so I'd rather prioritize not
regressing elsewhere unless there are good arguments...
If it helps fuzzing though I guess we could have this as a mount option?
but then you'd not be fuzzing the same code path as regular apps, so I'm
not convinced it's a good idea either...

[1] https://lore.kernel.org/all/1544532108-21689-3-git-send-email-asmadeus@xxxxxxxxxxxxx/T/#md5b45e3a9fda626a3e48489e12eed27a455707f7

Thanks,
-- 
Dominique Martinet | Asmadeus