Re: [BUG] 9p: fd: p9_conn_cancel publishes status before t_err

[Dominique Martinet]

(I didn't read 90% of that mail)

Rahul Priolkar wrote on Fri, Sep 11, 2026 at 02:21:32AM -0700:
> Conflicting accesses
> --------------------
> 
> The conflicting read is in p9_client_rpc() at net/9p/client.c:612:
> 
>     if (READ_ONCE(req->status) == REQ_STATUS_ERROR) {
>             ...
>             err = req->t_err;          /* racing read */
>     }
> 
> The conflicting write is in p9_conn_cancel() at net/9p/trans_fd.c:182.
> In the same function, req->status is published at line 169 or 173 before
> the lock is released at line 176 (abridged):
> 
>     spin_lock(&m->req_lock);
>     ...
>     WRITE_ONCE(req->status, REQ_STATUS_ERROR);
>     ...
>     spin_unlock(&m->req_lock);
> 
>     ...
>     if (!req->t_err)
>             req->t_err = err;          /* racing write */

That looks like a bug, if someone cares we could set all the errs first,
wmb, then set status to error before dropping the lock; at this point
I'm starting to wonder if we could just run the cb under lock but either
way I've given up on fighting with connection teardown bugs.

Please send a patch if you have time to check what you're doing
-- 
Dominique