From: Michal Pecio <michal.pecio@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: 胡连勤 <hulianqin@vivo.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Lee Jones" <lee@kernel.org>,
"Mathias Nyman" <mathias.nyman@linux.intel.com>,
"Mathias Nyman" <mathias.nyman@intel.com>,
"Sarah Sharp" <sarah.a.sharp@linux.intel.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: xhci: check Null pointer in segment alloc
Date: Mon, 22 Dec 2025 22:03:49 +0100 [thread overview]
Message-ID: <20251222220349.2d6c1a43.michal.pecio@gmail.com> (raw)
In-Reply-To: <38822950-6d69-4ad6-be28-fb8f328c8ae5@rowland.harvard.edu>
On Mon, 22 Dec 2025 12:03:45 -0500, Alan Stern wrote:
> There's not supposed to be an inappropriate time for doing an
> autoresume.
> By the time the sound device's resume routine runs, the HC should be
> fully resumed.
OK, if "should" means "supposed to" then somebody needs to check it.
Is this the HCD_FLAG_HW_ACCESSIBLE flag by any chance?
I see that devices recursively call bus_resume() before resuming, and
this fails with -ESHUTDOWN if the flag is unset, which seems to prevent
device resume from progressing further and crashing. Is this what is
meant to happen in such case?
So I guess it's not happening because xhci_resume() sets this flag
right away and then it may drop the lock and start deallocating memory
to reset everything. So we can "successfully" complete bus_resume()
and allow USB devices to resume while HC resume is still in progress.
Looks dodgy and I suspect this is the bug.
next prev parent reply other threads:[~2025-12-22 21:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 7:18 [PATCH] usb: xhci: check Null pointer in segment alloc 胡连勤
2025-12-19 12:48 ` Mathias Nyman
2025-12-19 15:53 ` 答复: " 胡连勤
2025-12-20 8:08 ` Greg Kroah-Hartman
2025-12-20 11:34 ` 答复: " 胡连勤
2025-12-20 13:15 ` Michal Pecio
2025-12-21 5:48 ` 答复: " 胡连勤
2025-12-22 6:42 ` Lee Jones
2025-12-22 7:13 ` Greg Kroah-Hartman
2025-12-22 7:55 ` Michal Pecio
2025-12-22 12:21 ` 答复: " 胡连勤
2025-12-22 13:34 ` Alan Stern
2025-12-22 16:49 ` Michal Pecio
2025-12-22 17:03 ` Alan Stern
2025-12-22 21:03 ` Michal Pecio [this message]
2025-12-23 3:24 ` Alan Stern
2025-12-23 10:06 ` Michal Pecio
2025-12-23 18:37 ` Alan Stern
2025-12-23 19:43 ` Michal Pecio
2025-12-22 14:00 ` 答复: " Greg Kroah-Hartman
2026-04-29 2:50 ` 答复: " 胡连勤
2026-04-29 7:44 ` Michal Pecio
2026-04-29 10:44 ` Mathias Nyman
2026-04-30 2:01 ` 答复: " 胡连勤
2026-04-30 2:18 ` 胡连勤
2025-12-21 16:22 ` Greg Kroah-Hartman
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=20251222220349.2d6c1a43.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hulianqin@vivo.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=sarah.a.sharp@linux.intel.com \
--cc=stern@rowland.harvard.edu \
/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.