From: Oleg Nesterov oleg@redhat.com
[ Upstream commit e8fe3f07a357c39d429e02ca34f740692d88967a ]
p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list).
However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 ("pipe_read: don't wake up the writer if the pipe is still full").
p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq).
This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT.
Reported-by: syzbot+d1b5dace43896bc386c3@syzkaller.appspotmail.com Tested-by: syzbot+d1b5dace43896bc386c3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68a2de8f.050a0220.e29e5.0097.GAE@google.com/ Link: https://lore.kernel.org/all/67dedd2f.050a0220.31a16b.003f.GAE@google.com/ Co-developed-by: K Prateek Nayak kprateek.nayak@amd.com Signed-off-by: K Prateek Nayak kprateek.nayak@amd.com Signed-off-by: Oleg Nesterov oleg@redhat.com Tested-by: K Prateek Nayak kprateek.nayak@amd.com Message-ID: 20250819161013.GB11345@redhat.com Signed-off-by: Dominique Martinet asmadeus@codewreck.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES – Calling `p9_poll_mux(m)` directly from `p9_fd_request()` restores the read-side kick that was lost when `pipe_read()` stopped waking writers, preventing 9p transports from stalling once their pipe fills.
**Key Points** - `net/9p/trans_fd.c:688` now invokes `p9_poll_mux(m)` right after a request is queued, so the mux re-evaluates readiness instead of only relying on the write-ready bit. - `net/9p/trans_fd.c:622-652` shows that `p9_poll_mux()` schedules both read and write work: with the new call it can react to `EPOLLIN`, set `Rpending`, and queue `m->rq`, which is exactly what the syzbot report needed to drain a full pipe. - `net/9p/trans_fd.c:394-402` (in `p9_read_work()`) demonstrates why this matters: the read worker only reschedules when `Rpending` is set; without the new kick the queue stayed full after commit aaec5a95d59615, blocking all further writes. - The change is contained to the 9p fd transport, touches no external APIs, and is a regression fix confirmed by syzbot, making it a safe and targeted backport candidate.
Given the regression impact (total hang under load) and the minimal, well-scoped fix, this should be backported to the affected stable kernels. Consider running the syzkaller reproducer or a 9p workload test after backporting to confirm the stall is gone.
net/9p/trans_fd.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c index 8992d8bebbddf..a516745f732f7 100644 --- a/net/9p/trans_fd.c +++ b/net/9p/trans_fd.c @@ -666,7 +666,6 @@ static void p9_poll_mux(struct p9_conn *m)
static int p9_fd_request(struct p9_client *client, struct p9_req_t *req) { - __poll_t n; int err; struct p9_trans_fd *ts = client->trans; struct p9_conn *m = &ts->conn; @@ -686,13 +685,7 @@ static int p9_fd_request(struct p9_client *client, struct p9_req_t *req) list_add_tail(&req->req_list, &m->unsent_req_list); spin_unlock(&m->req_lock);
- if (test_and_clear_bit(Wpending, &m->wsched)) - n = EPOLLOUT; - else - n = p9_fd_poll(m->client, NULL, NULL); - - if (n & EPOLLOUT && !test_and_set_bit(Wworksched, &m->wsched)) - schedule_work(&m->wq); + p9_poll_mux(m);
return 0; }