[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251222220349.2d6c1a43.michal.pecio@gmail.com>
Date: Mon, 22 Dec 2025 22:03:49 +0100
From: Michal Pecio <michal.pecio@...il.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: 胡连勤 <hulianqin@...o.com>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Lee Jones <lee@...nel.org>, Mathias Nyman
<mathias.nyman@...ux.intel.com>, Mathias Nyman <mathias.nyman@...el.com>,
Sarah Sharp <sarah.a.sharp@...ux.intel.com>, "linux-usb@...r.kernel.org"
<linux-usb@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: xhci: check Null pointer in segment alloc
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.
Powered by blists - more mailing lists