All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.