[PATCH] usb: xhci: fix maximum event ring segments calculation

[PATCH] usb: xhci: fix maximum event ring segments calculation

[oushixiong1025]

From: Shixiong Ou <oushixiong@kylinos.cn>

Commit 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros")
converted BIT(HCS_ERST_MAX(hcs_params2)) into
FIELD_GET(HCS_ERST_MAX, hcs_params2) << 2. The ERST Max field is a
power-of-two exponent, so the maximum number of segments is 2^n, not
n * 4.

With an ERST Max of 0 (as reported by e.g. QEMU xHCI) max_segs becomes
0, the event ring is allocated with 0 segments, and the resulting
zero-sized ERST allocation trips the page allocator:

  WARNING: mm/page_alloc.c:5340 at __alloc_frozen_pages_noprof+0x11d0/0x1548, CPU#0: swapper/0/1
  Call trace:
   __alloc_frozen_pages_noprof+0x11d0/0x1548 (P)
   alloc_pages_node_noprof+0xa0/0x108
   __dma_direct_alloc_pages.isra.0+0x178/0x260
   dma_direct_alloc+0x1e4/0x460
   dma_alloc_attrs+0xb4/0x2e8
   xhci_alloc_interrupter+0xdc/0x1c8
   xhci_mem_init+0x250/0xe70
   xhci_gen_setup+0x35c/0x4f0
   xhci_pci_setup+0x68/0x138
   usb_add_hcd+0x31c/0x640
   usb_hcd_pci_probe+0x1fc/0x3d8
   ...
  xhci_hcd 0000:02:00.0: Failed to allocate interrupter erst
  xhci_hcd 0000:02:00.0: can't setup: -12

Restore the BIT() based calculation.

Fixes: 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros")
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
---
 drivers/usb/host/xhci-mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 7a21ac81f9c8..af8d4b74c4ba 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2301,7 +2301,7 @@ xhci_alloc_interrupter(struct xhci_hcd *xhci, unsigned int segs, gfp_t flags)
 	if (!segs)
 		segs = ERST_DEFAULT_SEGS;
 
-	max_segs = FIELD_GET(HCS_ERST_MAX, xhci->hcs_params2) << 2;
+	max_segs = BIT(FIELD_GET(HCS_ERST_MAX, xhci->hcs_params2));
 	segs = min(segs, max_segs);
 
 	ir = kzalloc_node(sizeof(*ir), flags, dev_to_node(dev));
-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Pierre-David Belanger]

I ran into this independently on x86_64 under QEMU and had a regression
report half written when I found your patch. Same one line, same reasoning.

Confirmed against vanilla mainline 08dbfad3f504, with v7.2 built from the same
config for comparison:

  v7.2 (8d3ae59288f1)           USB keyboard enumerates
  08dbfad3f504                  xhci_hcd does not probe
  08dbfad3f504 + this patch     USB keyboard enumerates again

The failure on 08dbfad3f504:

  xhci_hcd 0000:00:04.0: xHCI Host Controller
  xhci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
  xhci_hcd 0000:00:04.0: Failed to allocate interrupter erst
  xhci_hcd 0000:00:04.0: can't setup: -12
  xhci_hcd 0000:00:04.0: USB bus 1 deregistered
  xhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -12
  xhci_hcd 0000:00:04.0: probe with driver xhci_hcd failed with error -12

Reproduced with:

  qemu-system-x86_64 -enable-kvm -m 512 -display none -serial stdio \
      -kernel bzImage -initrd initrd \
      -device qemu-xhci -device usb-kbd

Both -device qemu-xhci and -device nec-usb-xhci are affected. Reading
HCSPARAMS2 from inside the guest gives 0x0000000f, so ERST Max really is 0
and max_segs comes out as 0 with the current code.

I did not see the page allocator WARNING you hit (my .config is a minimal
tinyconfig-derived one), but the probe failure and the -12 are identical,
and this patch fixes it.

Tested-by: Pierre-David Belanger <pierredavidbelanger@gmail.com>

Thanks for the quick fix.

Pierre-David

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Thorsten Leemhuis]

On 8/30/26 05:12, Pierre-David Belanger wrote:

> The failure on 08dbfad3f504:
> 
>   xhci_hcd 0000:00:04.0: xHCI Host Controller
>   xhci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
>   xhci_hcd 0000:00:04.0: Failed to allocate interrupter erst
>   xhci_hcd 0000:00:04.0: can't setup: -12
>   xhci_hcd 0000:00:04.0: USB bus 1 deregistered
>   xhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -12
>   xhci_hcd 0000:00:04.0: probe with driver xhci_hcd failed with error -12
FWIW, not my area of expertise, but to me it looks like there were two
similar fixes submitted earlier to address this and "usb: xhci: Fix
HCS_ERST_MAX conversion" (
https://lore.kernel.org/all/20260828105926.930033-1-oushixiong1025@163.com/
) seems to be heading towards mainline already according to Mathias.
Sadly this missed -rc1, wonder why it wasn't submitted for it to prevent
more people from running into this, but whatever, that's ship has sailed.

Ciao, Thorsten

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Mathias Nyman]

Hi

On 8/28/26 13:59, oushixiong1025@163.com wrote:
> From: Shixiong Ou <oushixiong@kylinos.cn>
> 
> Commit 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros")
> converted BIT(HCS_ERST_MAX(hcs_params2)) into
> FIELD_GET(HCS_ERST_MAX, hcs_params2) << 2. The ERST Max field is a
> power-of-two exponent, so the maximum number of segments is 2^n, not
> n * 4.
> 
> With an ERST Max of 0 (as reported by e.g. QEMU xHCI) max_segs becomes
> 0, the event ring is allocated with 0 segments, and the resulting
> zero-sized ERST allocation trips the page allocator:

Thanks for the report and fix.

This issue was reported earlier and is address in:

https://lore.kernel.org/linux-usb/7e6648ad-7459-4248-8c6c-227cfc2586d8@linux.intel.com/

That patch is on its way upstream.

Good to get verification the fix (very similar) solves the issue for you as well.

Thanks
Mathias

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Mathias Nyman]

On 8/31/26 09:55, Thorsten Leemhuis wrote:
> On 8/30/26 05:12, Pierre-David Belanger wrote:
> 
>> The failure on 08dbfad3f504:
>>
>>    xhci_hcd 0000:00:04.0: xHCI Host Controller
>>    xhci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
>>    xhci_hcd 0000:00:04.0: Failed to allocate interrupter erst
>>    xhci_hcd 0000:00:04.0: can't setup: -12
>>    xhci_hcd 0000:00:04.0: USB bus 1 deregistered
>>    xhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -12
>>    xhci_hcd 0000:00:04.0: probe with driver xhci_hcd failed with error -12
> FWIW, not my area of expertise, but to me it looks like there were two
> similar fixes submitted earlier to address this and "usb: xhci: Fix
> HCS_ERST_MAX conversion" (
> https://lore.kernel.org/all/20260828105926.930033-1-oushixiong1025@163.com/
> ) seems to be heading towards mainline already according to Mathias.
> Sadly this missed -rc1, wonder why it wasn't submitted for it to prevent
> more people from running into this, but whatever, that's ship has sailed.

Looks like at least QEMU and Mediatek users were hit by this issue.

Note that this is a v7.3-rc1 regression which was found during merge window for v7.3-rc1.
v7.3-rc1 came out a few hours ago.
I can't resolve it much earlier than this.

Thanks
Mathias

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Thorsten Leemhuis]

On 8/31/26 11:21, Mathias Nyman wrote:
> On 8/31/26 09:55, Thorsten Leemhuis wrote:
>> On 8/30/26 05:12, Pierre-David Belanger wrote:
>>> The failure on 08dbfad3f504:
>>>
>>>    xhci_hcd 0000:00:04.0: xHCI Host Controller
>>>    xhci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
>>>    xhci_hcd 0000:00:04.0: Failed to allocate interrupter erst
>>>    xhci_hcd 0000:00:04.0: can't setup: -12
>>>    xhci_hcd 0000:00:04.0: USB bus 1 deregistered
>>>    xhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -12
>>>    xhci_hcd 0000:00:04.0: probe with driver xhci_hcd failed with
>>> error -12
>> Sadly this missed -rc1, wonder why it wasn't submitted for it to prevent
>> more people from running into this, but whatever, that's ship has sailed.
> 
> Looks like at least QEMU and Mediatek users were hit by this issue.

Ahh, good to known. And thx for sending one of the fixes to Greg
meanwhile (saw that by chance).
> Note that this is a v7.3-rc1 regression which was found during merge
> window for v7.3-rc1.
> v7.3-rc1 came out a few hours ago.
> I can't resolve it much earlier than this.
Out of curiosity: why?

Just ignore the question if it was something like "real life got in the
way" or "it fell through the cracks" -- that's how it is sometimes, no
worries. But in other cases I'd be glad if you could take a few minutes
if you have them to satisfy my curiosity, as in preparation for a
maintainer summit proposal I sent[1] I'm just trying to understand
better why regression fixes sometimes take quite a while from submission
to landing in mainline

Ciao, Thorsten

[1]
https://lore.kernel.org/all/75dc0e2d-2deb-4776-977c-1de7c33465e1@leemhuis.info/

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Thorsten Leemhuis]

On 8/31/26 13:28, Thorsten Leemhuis wrote:
> On 8/31/26 11:21, Mathias Nyman wrote:
>> On 8/31/26 09:55, Thorsten Leemhuis wrote:
>>> On 8/30/26 05:12, Pierre-David Belanger wrote:
>>>> The failure on 08dbfad3f504:
>>>>
>>>>    xhci_hcd 0000:00:04.0: xHCI Host Controller
>>>>    xhci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
>>>>    xhci_hcd 0000:00:04.0: Failed to allocate interrupter erst
>>>>    xhci_hcd 0000:00:04.0: can't setup: -12
>>>>    xhci_hcd 0000:00:04.0: USB bus 1 deregistered
>>>>    xhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -12
>>>>    xhci_hcd 0000:00:04.0: probe with driver xhci_hcd failed with
>>>> error -12
>>> Sadly this missed -rc1, wonder why it wasn't submitted for it to prevent
>>> more people from running into this, but whatever, that's ship has sailed.
>>
>> Looks like at least QEMU and Mediatek users were hit by this issue.
> 
> Ahh, good to known. And thx for sending one of the fixes to Greg
> meanwhile (saw that by chance).
>> Note that this is a v7.3-rc1 regression which was found during merge
>> window for v7.3-rc1.
>> v7.3-rc1 came out a few hours ago.
>> I can't resolve it much earlier than this.
> Out of curiosity: why?
> 
> Just ignore the question if it was something like "real life got in the
> way" or "it fell through the cracks" -- that's how it is sometimes, no
> worries. But in other cases I'd be glad if you could take a few minutes
> if you have them to satisfy my curiosity, as in preparation for a
> maintainer summit proposal I sent[1] I'm just trying to understand
> better why regression fixes sometimes take quite a while from submission
> to landing in mainline

For the record (sorry, this should have bin in above mail!), as it might
sound hostile without context, as obviously there would not have been
enough time to fix this if the issue would only have become known during
the end of the merge window. But that is not the case here afaics
(please correct me if I'm wrong!), as the first patch to fix this was
afaics submitted on 2026-08-20:

https://lore.kernel.org/linux-usb/7e6648ad-7459-4248-8c6c-227cfc2586d8@linux.intel.com/

> [1]
> https://lore.kernel.org/all/75dc0e2d-2deb-4776-977c-1de7c33465e1@leemhuis.info/

Ciao, THorsten

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Mathias Nyman]

On 8/31/26 14:36, Thorsten Leemhuis wrote:
> 
> 
> On 8/31/26 13:28, Thorsten Leemhuis wrote:
>> On 8/31/26 11:21, Mathias Nyman wrote:
>>> On 8/31/26 09:55, Thorsten Leemhuis wrote:
>>>> On 8/30/26 05:12, Pierre-David Belanger wrote:
>>>>> The failure on 08dbfad3f504:
>>>>>
>>>>>     xhci_hcd 0000:00:04.0: xHCI Host Controller
>>>>>     xhci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
>>>>>     xhci_hcd 0000:00:04.0: Failed to allocate interrupter erst
>>>>>     xhci_hcd 0000:00:04.0: can't setup: -12
>>>>>     xhci_hcd 0000:00:04.0: USB bus 1 deregistered
>>>>>     xhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -12
>>>>>     xhci_hcd 0000:00:04.0: probe with driver xhci_hcd failed with
>>>>> error -12
>>>> Sadly this missed -rc1, wonder why it wasn't submitted for it to prevent
>>>> more people from running into this, but whatever, that's ship has sailed.
>>>
>>> Looks like at least QEMU and Mediatek users were hit by this issue.
>>
>> Ahh, good to known. And thx for sending one of the fixes to Greg
>> meanwhile (saw that by chance).
>>> Note that this is a v7.3-rc1 regression which was found during merge
>>> window for v7.3-rc1.
>>> v7.3-rc1 came out a few hours ago.
>>> I can't resolve it much earlier than this.
>> Out of curiosity: why?
>>
>> Just ignore the question if it was something like "real life got in the
>> way" or "it fell through the cracks" -- that's how it is sometimes, no
>> worries. But in other cases I'd be glad if you could take a few minutes
>> if you have them to satisfy my curiosity, as in preparation for a
>> maintainer summit proposal I sent[1] I'm just trying to understand
>> better why regression fixes sometimes take quite a while from submission
>> to landing in mainline

No real life or personal issues got in the way.
Assumed severity after first case didn't call for action mid merge window.

> 
> For the record (sorry, this should have bin in above mail!), as it might
> sound hostile without context, as obviously there would not have been
> enough time to fix this if the issue would only have become known during
> the end of the merge window. But that is not the case here afaics
> (please correct me if I'm wrong!), as the first patch to fix this was
> afaics submitted on 2026-08-20:

Sure, I'll describe how it went

2026-08-16 Sunday,

   v7.2 is tagged, merge window opens
   I've sent all my patches, assume Greg has his pull request ready for Linus.

2026-08-20 Thursday,
  
   I see the issue and patch the first time.
   It points to an issue in next, is valid but commit message doesn't call for
   urgency in any way.
   Doesn't specify which hardware is concerned.
   So far one report only. I haven't seen the issue myself so assume it's some obscure
   hardware (pre-production, or virtual/firmware).
   Queue for after rc1.
   No reason to panic or bother Greg or Linus mid merge window at this stage.

2026-08-27 Thursday, a week later, rc1 will be tagged on Sunday

   I get a second report for the same issue, this one shows it concerns Mediatek MT8173.
   Issue gets my attention, rc1 will be tagged on Sunday so I don't even consider stirring
   up anything anymore.

   https://lore.kernel.org/linux-usb/20260827053748.3755-1-getfeus@gmail.com


2026-08-28 Friday

   One more case, showing this  affects QEMU users as well.
   But no point in sending anything before rc1 anymore, rc1 will be tagged on Sunday
     
2026-08-30 Sunday
   
   another QEMU user reports an issue
   Linus tags 7.3-rc1

2026-08-31 Monday

   Rebase on rc1, compile, quick testrun, submit fix to Greg.

Thanks
Mathias

Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Thorsten Leemhuis]

On 8/31/26 16:28, Mathias Nyman wrote:
> On 8/31/26 14:36, Thorsten Leemhuis wrote:
>> On 8/31/26 13:28, Thorsten Leemhuis wrote:
>>> On 8/31/26 11:21, Mathias Nyman wrote:
>>>> On 8/31/26 09:55, Thorsten Leemhuis wrote:
>>>>> On 8/30/26 05:12, Pierre-David Belanger wrote:
>
>>>> Note that this is a v7.3-rc1 regression which was found during merge
>>>> window for v7.3-rc1.
>>>> v7.3-rc1 came out a few hours ago.
>>>> I can't resolve it much earlier than this.
>>> Out of curiosity: why?
> [...]
> No real life or personal issues got in the way.
> Assumed severity after first case didn't call for action mid merge window. 

Many thx, that helps me understand thing better.

Quite a few other subsystems from what I see would have approached
things just like you did here; but I wonder if Linus in a case like this
would have preferred some mid/late merge window intervention to prevent
testers from running into a known regression. Will try to bring this up
on the maintainers summit. So again, thx again for describing things
from your point of view, helps a lot.

Ciao, Thorsten