From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Sang-Hoon Choi <csh0052@gmail.com>,
Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, Changyul Lee <lcy8047@gmail.com>
Subject: Re: [PATCH] xhci: dbc: lock the minor IDR on registration failure
Date: Mon, 5 Oct 2026 18:28:04 +0300 [thread overview]
Message-ID: <93f1090f-ed09-4e76-8621-c30583bdac58@linux.intel.com> (raw)
In-Reply-To: <20261003.final086.034e184ae398239b@gmail.com>
On 10/2/26 22:47, Sang-Hoon Choi wrote:
> dbc_tty_minors is protected by dbc_tty_minors_lock when entries are
> allocated and during normal device removal. The registration error path
> removes an entry without taking that lock. Different DbC instances have
> separate event work items, so this removal can race with an IDR update
> for another instance.
>
> Take the same mutex around the error-path removal.
>
> Fixes: e1ec140f273e ("xhci: dbgtty: use IDR to support several dbc instances.")
> Reported-by: Changyul Lee <lcy8047@gmail.com>
> Assisted-by: LLM
> Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
> ---
> Compile-tested the affected object with x86_64 allmodconfig
> and W=1 (GCC 13.3.0). Base: mainline 3b7cab693ba2bab63774bf5b988e8a61b2ef0f32.
> No hardware testing or runtime failure reproduction was performed.
>
> drivers/usb/host/xhci-dbgtty.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c
> index 3d51e8d82659..2249cc16800c 100644
> --- a/drivers/usb/host/xhci-dbgtty.c
> +++ b/drivers/usb/host/xhci-dbgtty.c
> @@ -535,7 +535,9 @@ static int xhci_dbc_tty_register_device(struct xhci_dbc *dbc)
> err_free_fifo:
> kfifo_free(&port->port.xmit_fifo);
> err_exit_port:
> + mutex_lock(&dbc_tty_minors_lock);
> idr_remove(&dbc_tty_minors, port->minor);
> + mutex_unlock(&dbc_tty_minors_lock);
> err_idr:
> xhci_dbc_tty_exit_port(port);
>
Thanks
Adding to queue
As an additional remark it seems that this issue is a bit theoretical.
We just allocated that id in the same function a few lines earlier (while protected
by the mutex).
The tty port device never got registered or used in this error path, so nothing will
try to use or find anything with this specific id.
I think internal XArray synchronization working underneath IDR can probably manage
idr_find(), idr_alloc() and idr_remove() calls for other ids even if this one is being
removed at the same time, but not 100% sure.
Let me know if you can describe a scenario where current idr_remove() in the error
path without the mutex protection is an issue.
Thanks
Mathias
prev parent reply other threads:[~2026-10-05 15:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 19:47 [PATCH] xhci: dbc: lock the minor IDR on registration failure Sang-Hoon Choi
2026-10-05 15:28 ` Mathias Nyman [this message]
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=93f1090f-ed09-4e76-8621-c30583bdac58@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=csh0052@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=lcy8047@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox