From: Dominique Martinet <asmadeus@codewreck.org>
To: Hyungjung Joo <jhj140711@gmail.com>
Cc: ericvh@kernel.org, lucho@ionkov.net, linux_oss@crudebyte.com,
m.grzeschik@pengutronix.de, gregkh@linuxfoundation.org,
v9fs@lists.linux.dev, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] net: 9p: usbg: clear stale client pointer on close
Date: Sat, 14 Mar 2026 15:01:25 +0900 [thread overview]
Message-ID: <abT5tabfYV9a9RF_@codewreck.org> (raw)
In-Reply-To: <20260313171659.1225180-1-jhj140711@gmail.com>
Hyungjung Joo wrote on Sat, Mar 14, 2026 at 02:16:59AM +0900:
> p9_usbg_close() tears down the client transport, but usb9pfs keeps
> using usb9pfs->client from asynchronous TX and RX completion handlers.
> A late completion can therefore dereference a client that has already
> been freed during mount teardown.
>
> Clear usb9pfs->client under usb9pfs->lock when closing the transport,
> detach any pending TX request from in_req->context, and make the TX/RX
> completion handlers bail out once the transport has been detached. This
> keeps late completions from touching a freed or rebound p9_client.
Just to make sure the problem is the usb9pfs struct being freed, not the
p9_client itself which is still alive after the usb device is gone
(until umount)?
I'm surprised free_func isn't called after unbind, which should stop the
queues (through disable_usb9pfs)?
or are the ep being disabled not enough to ensure the callbacks are not
in use? (e.g. disabling prevents further calls, but doesn't wait for
currently running/queued requests?)
(Also, thanks Michael for looking -- I'll let you do a first review
before looking deeper)
--
Dominique
next prev parent reply other threads:[~2026-03-14 6:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 17:16 [PATCH] net: 9p: usbg: clear stale client pointer on close Hyungjung Joo
2026-03-13 18:06 ` Michael Grzeschik
2026-03-14 6:01 ` Dominique Martinet [this message]
2026-03-14 7:24 ` Hyungjung Joo
2026-03-14 12:30 ` Dominique Martinet
2026-03-18 14:33 ` Michael Grzeschik
2026-03-18 14:49 ` Hyungjung Joo
2026-03-18 23:24 ` Michael Grzeschik
2026-03-19 0:30 ` Dominique Martinet
2026-03-19 9:16 ` Michael Grzeschik
2026-03-19 9:22 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abT5tabfYV9a9RF_@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jhj140711@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=m.grzeschik@pengutronix.de \
--cc=stable@vger.kernel.org \
--cc=v9fs@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.