New: kernel warning: DMA-API: xhci_hcd: cacheline tracking EEXIST, overlapping mappings aren't supported

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Bug ID: 215740
Summary: kernel warning: DMA-API: xhci_hcd: cacheline tracking
EEXIST, overlapping mappings aren't supported
Product: Drivers
Version: 2.5
Kernel Version: 5.17
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

Created attachment 300612
--> https://bugzilla.kernel.org/attachment.cgi?id=300612&action=edit
full dmesg log with the warning

I have this kernel trace often while PC booting:

DMA-API: xhci_hcd 0000:09:00.3: cacheline tracking EEXIST, overlapping
mappings aren't supported

    WARNING: CPU: 4 PID: 69 at kernel/dma/debug.c:570 add_dma_entry+0x1c7/0x250
    Modules linked in: bpf_preload
    CPU: 4 PID: 69 Comm: kworker/4:1 Not tainted 5.17.0 #1
    Hardware name: ASUS System Product Name/TUF GAMING B550M-PLUS, BIOS 2423
08/10/2021
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:add_dma_entry+0x1c7/0x250
    Code: ff 0f 84 97 00 00 00 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 4b 53 80
00 48 89 c6 48 89 da 48 c7 c7 58 b3 84 94 e8 27 21 ca 00 <0f> 0b 48 85 ed 0f 85
69 d2 ca 00 8b 05 88 a0 30 02 85 c0 0f 85 f4
    RSP: 0018:ffff9cadc0c9ba88 EFLAGS: 00010292
    RAX: 0000000000000060 RBX: ffff9173d2c49ea0 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff
    RBP: ffff9173d11a5e80 R08: 0000000000000000 R09: ffff9cadc0c9b8c0
    R10: ffff9cadc0c9b8b8 R11: ffffffff95165128 R12: 0000000000000000
    R13: 0000000000000001 R14: 0000000000000206 R15: 00000000046882ee
    FS:  0000000000000000(0000) GS:ffff9182a8200000(0000)
knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fce5d52a130 CR3: 0000000119b28000 CR4: 0000000000350ee0
    Call Trace:
    <TASK>
    dma_map_page_attrs+0x82/0x250
    ? _raw_spin_unlock_irqrestore+0x30/0x60
    usb_hcd_map_urb_for_dma+0x3eb/0x4f0
    usb_hcd_submit_urb+0x9b/0xb90
    ? lockdep_init_map_type+0x62/0x260
    usb_start_wait_urb+0x55/0x130
    usb_control_msg+0xc9/0x110
    hub_ext_port_status+0x89/0x110
    hub_event+0x1e4/0x1920
    ? lock_acquire+0xe0/0x2d0
    ? lock_is_held_type+0xea/0x140
    process_one_work+0x29b/0x5f0
    worker_thread+0x4f/0x390
    ? process_one_work+0x5f0/0x5f0
    kthread+0xf5/0x120
    ? kthread_complete_and_exit+0x20/0x20
    ret_from_fork+0x22/0x30
    </TASK>

My usb devices:

$ lsusb -t
    /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
        |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
            |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
                |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M
                |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 5000M
                    |__ Port 4: Dev 6, If 0, Class=Hub, Driver=hub/4p, 5000M
    /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
        |__ Port 2: Dev 2, If 3, Class=Application Specific Interface, Driver=,
12M
        |__ Port 2: Dev 2, If 1, Class=Vendor Specific Class, Driver=btusb, 12M
        |__ Port 2: Dev 2, If 2, Class=Vendor Specific Class, Driver=btusb, 12M
        |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=btusb, 12M
        |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 12, If 0, Class=Communications, Driver=cdc_ether,
480M
            |__ Port 1: Dev 12, If 1, Class=CDC Data, Driver=cdc_ether, 480M
            |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
                |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
                    |__ Port 3: Dev 6, If 1, Class=Human Interface Device,
Driver=usbhid, 1.5M
                    |__ Port 3: Dev 6, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
                    |__ Port 4: Dev 7, If 0, Class=Hub, Driver=hub/4p, 480M
                        |__ Port 2: Dev 8, If 0, Class=Human Interface Device,
Driver=usbfs, 1.5M
                        |__ Port 3: Dev 9, If 0, Class=Vendor Specific Class,
Driver=, 480M
                        |__ Port 4: Dev 10, If 0, Class=Imaging, Driver=, 480M
    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
        |__ Port 6: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid,
12M
        |__ Port 6: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M
        |__ Port 7: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M

$ lsusb
    Bus 004 Device 006: ID 2109:0812 VIA Labs, Inc. VL812 Hub
    Bus 004 Device 005: ID 2109:0812 VIA Labs, Inc. VL812 Hub
    Bus 004 Device 004: ID 0578:0578 Intrinsix Corp. KingSpec
    Bus 004 Device 003: ID 2109:0812 VIA Labs, Inc. VL812 Hub
    Bus 004 Device 002: ID 2109:0812 VIA Labs, Inc. VL812 Hub
    Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 003 Device 010: ID 1004:633e LG Electronics, Inc. LM-X420xxx/G2/G3
Android Phone (MTP/download mode)
    Bus 003 Device 009: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU
802.11a/b/g/n/ac 2T2R DB WLAN Adapter
    Bus 003 Device 008: ID 0463:ffff MGE UPS Systems UPS
    Bus 003 Device 007: ID 2109:2812 VIA Labs, Inc. VL812 Hub
    Bus 003 Device 006: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49)
    Bus 003 Device 005: ID 2109:2812 VIA Labs, Inc. VL812 Hub
    Bus 003 Device 004: ID 2109:2812 VIA Labs, Inc. VL812 Hub
    Bus 003 Device 012: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB
Ethernet/RNDIS Gadget
    Bus 003 Device 003: ID 2109:2812 VIA Labs, Inc. VL812 Hub
    Bus 003 Device 002: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0
Bluetooth
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
    Bus 001 Device 002: ID 0b05:1939 ASUSTek Computer, Inc. AURA LED Controller
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Kernel is built from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
at v5.17 tag (f443e374ae131c168a065ea1748feac6b2e76613)

Also reproduces for my distro kernel:
https://bugzilla.redhat.com/show_bug.cgi?id=2021242

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- Am I right in assuming this didn't happen on earlier Linux versions like 5.16?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #2 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from
comment #1)

Forget that, should have looked in the redhat ticket before posting this, there you state that 5.13 seems to not be affected.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Hey Christoph, Marek, Greg!

Below warning was reported to bugzilla.kernel.org more than a week ago; to quote the important parts here:

See the full quote below for details.

According to a bugzilla.redhat.com ticket linked in the report this started to happen with 5.14. A second user there also confirmed the problem that still seems to happen with recent 5.17 pre-releases. Searching on lore revealed that others have hit this warning as well in the past few months:

https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/CABXGCsP-JJAUh-SV0u1ALu5+awxcWT3BsQ=FzKrqb+9HOk2EUA@mail.gmail.com/

Does anyone have a idea what might be wrong here? If not, I guess we should ask one of the reporters to bisect this.

Anyway, to ensure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced v5.13..v5.14
#regzbot title dma or usb: warning "DMA-API: xhci_hcd ... cacheline tracking EEXIST, overlapping mappings aren't supported" #regzbot from: Andrew <[email protected]>
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215740
#regzbot https://bugzilla.redhat.com/show_bug.cgi?id=2021242
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.

The warning is from a new debug check added in 5.14 under a debug config option. So while the USB maintainers should look into fixing it I don't think it is a regression in that traditional sense of the word.

TWIMC: this mail is primarily send for documentation purposes and for regzbot, my Linux kernel regression tracking bot. These mails usually contain '#forregzbot' in the subject, to make them easy to spot and filter.

#regzbot invalid: not a regressions, just and existing problem that became visible due to a new error message

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #3 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- Hey Christoph, Marek, Greg!

Below warning was reported to bugzilla.kernel.org more than a week ago; to quote the important parts here:

See the full quote below for details.

According to a bugzilla.redhat.com ticket linked in the report this started to happen with 5.14. A second user there also confirmed the problem that still seems to happen with recent 5.17 pre-releases. Searching on lore revealed that others have hit this warning as well in the past few months:

https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/CABXGCsP-JJAUh-SV0u1ALu5+awxcWT3BsQ=FzKrqb+9HOk2EUA@mail.gmail.com/

Does anyone have a idea what might be wrong here? If not, I guess we should ask one of the reporters to bisect this.

Anyway, to ensure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced v5.13..v5.14
#regzbot title dma or usb: warning "DMA-API: xhci_hcd ... cacheline tracking EEXIST, overlapping mappings aren't supported" #regzbot from: Andrew <[email protected]>
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215740
#regzbot https://bugzilla.redhat.com/show_bug.cgi?id=2021242
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Mathias Nyman ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
                   |                            |om

--- Comment #4 from Mathias Nyman ([email protected]) --- That warning was added in v5.14:
2b4bbc6231d7 dma-debug: report -EEXIST errors in add_dma_entry

Actual issue on usb side could be a lot older.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #5 from Christoph Hellwig ([email protected]) ---

The warning is from a new debug check added in 5.14 under a debug config option. So while the USB maintainers should look into fixing it I don't think it is a regression in that traditional sense of the word.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Lukas Wunner ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #6 from Lukas Wunner ([email protected]) ---
Ferry Toth reports that the warning only occurs when connecting a LAN9514 USB Ethernet (drivers/net/usb/smsc95xx.c). Other USB devices (memory sticks, WiFi, Bluetooth) do not trigger the warning:

https://lore.kernel.org/netdev/[email protected]/

Curiously, the above-linked other reports seem to indicate that the warning occurs when connecting USB hubs. It's unclear what those have in common with the LAN9514.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Ferry Toth ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #7 from Ferry Toth ([email protected]) --- In my case it is EVM9514, a 4p USB hub + 10/100 ethernet:
https://www.microchip.com/en-us/development-tool/EVB9514

So, indeed it seems like to warning originates from hub code shared between at least VL812 and LAN9514.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Ferry Toth ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #8 from Ferry Toth ([email protected]) ---
I also heard from Andy Shevchenko that he had the same error using even another hub. It seems the error is not particular to a certain hub, but doesn't appear on root hubs.

And indeed when I plug my hub into Ubuntu the error doesn't occur because "debug check added in 5.14 under a debug config option" (Comment 5 above) is not enabled in Ubuntu kernels.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #9 from Ferry Toth ([email protected]) --- Ok, it's different then in #6 above.

smsc95xx behaves as a 5p hub, with an usb to ethernet adapter plugged into 1 port. So, 4 ports remain available to the user. The bug itself is likely located in hub.c.

I can reproduce this with an ordinary 7p hub (EVB USB2517). Plugging the hub causes no issues. Then plugging an usb device (in my case I just plugged a mouse) into a port triggers the "cacheline tracking EEXIST".

The warning occurs only once (regardless unplugging the device or the hub).

Note that on Ubuntu 23.10 the warning does not occur, but they have most debug options not set. So, likely this is an old bug that has gone undetected for a long while.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #10 from Ferry Toth ([email protected]) --- Seems might be caused from init3: usb_submit_urb() in hub_active()> I don't see why. May be Alan knows?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #11 from Alan Stern ([email protected]) ---
I don't think it has anything to do with the init3: section. The stack trace shows that the problem stems from hub_ext_port_status(), probably called by port_event() within hub_event(). And the place where hub_ext_port_status() calls usb_control_msg() indirectly is protected by a mutex!

The I/O buffer being mapped multiple times is hub->status->port, and it doesn't get used anywhere else in the hub driver AFAICS. (There is a comment about the phy driver also using that buffer; I don't know what it refers to.)

[It would be easier to track this down if the DMA subsystem would cause these erroneous mappings to fail instead of pretending that they have succeeded. Grumble...]

I'm stumped. I'll try to find time to reproduce it on my own system. Probably would have noticed it before now if I had tried connecting an external hub recently, but that just hasn't come up.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #12 from Ferry Toth ([email protected]) --- Ah, ok I was looking at a stack trace from a more recent kernel. So, here to add some more data points (2 different kernels):

This is with EVB LAN9514 plugged in while booting:

: ------------[ cut here ]------------
: DMA-API: dwc3 dwc3.0.auto: cacheline tracking EEXIST, overlapping mappings aren't supported
: WARNING: CPU: 1 PID: 32 at kernel/dma/debug.c:602 add_dma_entry+0x1eb/0x2b0 : Modules linked in: mmc_block extcon_intel_mrfld sdhci_pci cqhci sdhci led_class mmc_core intel_soc_pmic_mrfld btrfs libcrc32c xor zlib_deflate zstd_compress raid6_pq
: CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 6.6.0-next-20231106-edison-acpi-standard+ #1
: Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
: Workqueue: usb_hub_wq hub_event
: RIP: 0010:add_dma_entry+0x1eb/0x2b0
: Code: 0f 84 cc 00 00 00 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 48 1f 68 00 48 89 c6 4c 89 e2 48 c7 c7 80 04 3d a4 e8 76 fb f5 ff 90 <0f> 0b 90 90 48 85 ed 74 1a 48 c7 c7 68 84 35 a4 e8 f0 0c fd ff 8b
: RSP: 0000:ffffa5bb0021fab0 EFLAGS: 00010286
: RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000ffffdfff : RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 0000000000000001 : RBP: ffff9f50c122da80 R08: ffffffffa4738d08 R09: 00000000ffffdfff : R10: ffffffffa4658d20 R11: ffffffffa4708d20 R12: ffff9f50c2879550 : R13: 0000000000000001 R14: 0000000000000202 R15: 00000000002047f8 : FS: 0000000000000000(0000) GS:ffff9f50fe300000(0000) knlGS:0000000000000000 : CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
: CR2: 00005647b6a03c0f CR3: 0000000009ce0000 CR4: 00000000001006f0 : Call Trace:

:  <TASK>
:  ? __warn+0x7e/0x130
:  ? add_dma_entry+0x1eb/0x2b0
:  ? report_bug+0x18e/0x1a0
:  ? handle_bug+0x3d/0x70
:  ? exc_invalid_op+0x18/0x70
:  ? asm_exc_invalid_op+0x1a/0x20
:  ? add_dma_entry+0x1eb/0x2b0
:  dma_map_page_attrs+0x105/0x280
:  ? __virt_addr_valid+0xe7/0x130
:  usb_hcd_map_urb_for_dma+0x3c2/0x500
:  usb_hcd_submit_urb+0x9b/0xb70
:  ? kmem_cache_alloc+0x20d/0x230
:  ? usb_hcd_link_urb_to_ep+0x72/0xa0
:  ? prepare_transfer+0x104/0x140
:  usb_start_wait_urb+0x60/0x160
:  usb_control_msg+0xe0/0x150
:  hub_ext_port_status+0x85/0x1b0
:  hub_event+0x1f7/0x1ba0
:  ? hub_activate+0x59b/0x8f0
:  process_one_work+0x136/0x2f0
:  ? __pfx_worker_thread+0x10/0x10
:  worker_thread+0x2ed/0x400
:  ? __pfx_worker_thread+0x10/0x10
:  kthread+0xd3/0x100
:  ? __pfx_kthread+0x10/0x10
:  ret_from_fork+0x2f/0x50
:  ? __pfx_kthread+0x10/0x10
:  ret_from_fork_asm+0x1a/0x30
:  </TASK>
: ---[ end trace 0000000000000000 ]---
: DMA-API: Mapped at:
:  debug_dma_map_page+0x68/0x100
:  dma_map_page_attrs+0x105/0x280
:  usb_hcd_map_urb_for_dma+0x3c2/0x500
:  usb_hcd_submit_urb+0x9b/0xb70
:  usb_start_wait_urb+0x60/0x160

This is after boot, plugging the EVM-USB2517, then plugging a mouse:

------------[ cut here ]------------
DMA-API: dwc3 dwc3.0.auto: cacheline tracking EEXIST, overlapping mappings
aren't supported
WARNING: CPU: 0 PID: 587 at kernel/dma/debug.c:568 add_dma_entry+0x1ed/0x280
Modules linked in: rfcomm bnep iptable_nat snd_sof_nocodec spi_pxa2xx_platform
dw_dmac snd_sof_pci_intel_tng snd_sof_pci snd_sof_intel_atom pwm_lpss_pci
pwm_lpss>
CPU: 0 PID: 587 Comm: kworker/0:3 Not tainted 6.1.55-edison-acpi-standard #1
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
Workqueue: usb_hub_wq hub_event
RIP: 0010:add_dma_entry+0x1ed/0x280
Code: ff 0f 84 97 00 00 00 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 f5 a6 5a 00
48 89 c6 4c 89 e2 48 c7 c7 10 ed 62 b8 e8 e3 ce f7 ff <0f> 0b 48 85 ed 0f 85 4c
d3 >
RSP: 0018:ffffa3400066fae0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 0000000000000000
RDX: 0000000000000002 RSI: ffffffffb8634309 RDI: 00000000ffffffff
RBP: ffff92a981295f00 R08: ffffffffb8937828 R09: 00000000ffffdfff
R10: ffffffffb8857840 R11: ffffffffb8907840 R12: ffff92a982ca37a0
R13: 0000000000000001 R14: 0000000000000206 R15: 00000000000b716f
FS:  0000000000000000(0000) GS:ffff92a9be200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055bed6f3b078 CR3: 000000000e00c000 CR4: 00000000001006f0
Call Trace:
 <TASK>
 ? __warn+0x74/0xc0
 ? add_dma_entry+0x1ed/0x280
 ? report_bug+0xee/0x170
 ? prb_read_valid+0x12/0x20
 ? handle_bug+0x3c/0x70
 ? exc_invalid_op+0x14/0x70
 ? asm_exc_invalid_op+0x16/0x20
 ? add_dma_entry+0x1ed/0x280
 dma_map_page_attrs+0x101/0x270
 ? preempt_count_add+0x6b/0xa0
 ? preempt_count_add+0x6b/0xa0
 usb_hcd_map_urb_for_dma+0x410/0x570
 usb_hcd_submit_urb+0x97/0xb80
 ? hub_activate+0x2db/0x890
 ? hub_resume+0x2e/0xf0
 usb_start_wait_urb+0x60/0x160
 usb_control_msg+0xdc/0x140
 hub_ext_port_status+0x82/0x110
 hub_event+0x442/0x1840
 ? _raw_spin_unlock+0xd/0x30
 ? finish_task_switch.isra.0+0x89/0x260
 process_one_work+0x1d7/0x3a0
 worker_thread+0x48/0x3c0
 ? process_one_work+0x3a0/0x3a0
 kthread+0xe3/0x110
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 </TASK>
---[ end trace 0000000000000000 ]---
DMA-API: Mapped at:
 debug_dma_map_page+0x64/0x100
 dma_map_page_attrs+0x101/0x270
 usb_hcd_map_urb_for_dma+0x410/0x570
 usb_hcd_submit_urb+0x97/0xb80
 usb_start_wait_urb+0x60/0x160

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #13 from Alan Stern ([email protected]) --- Those two stack traces are essentially the same as the first one reported. They all contain the following key sequence of function calls:

dma_map_page_attrs
usb_hcd_map_urb_for_dma
usb_hcd_submit_urb
usb_start_wait_urb
usb_control_msg
hub_ext_port_status
hub_event
process_one_work

It doesn't look like they add anything new.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #14 from Ferry Toth ([email protected]) --- I see. I was misled by ? hub_activate, and hub_activate calling usb_submit_urb.

In any case the traces then show the problem is likely reproducible using any hub.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #15 from Alan Stern ([email protected]) --- Created attachment 305425
--> https://bugzilla.kernel.org/attachment.cgi?id=305425&action=edit
Diagnostics for overlapped DMA mapping

I just tried booting a kernel with CONFIG_DMA_API_DEBUG enabled. When I plugged in a hub and then plugged some devices into that hub, nothing went wrong.

So since I can't do any useful testing here, maybe one of you can test the attached patch. It won't fix anything but it should help confirm what's happening and provide a starting point for further debugging.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #16 from Ferry Toth ([email protected]) --- Created attachment 305426
--> https://bugzilla.kernel.org/attachment.cgi?id=305426&action=edit
ftrace, hub plugged at 131, mouse plugged into hub at 141

Sure. And added a ftrace see attachment trace_hub.txt.

In journal I got:
...

Nov 19 20:57:45 yuna kernel: ---[ end trace 0000000000000000 ]---
Nov 19 20:57:45 yuna kernel: DMA-API: Mapped at:
Nov 19 20:57:45 yuna kernel:  debug_dma_map_page+0x6d/0x100
Nov 19 20:57:45 yuna kernel:  dma_map_page_attrs+0x10a/0x280
Nov 19 20:57:45 yuna kernel:  usb_hcd_map_urb_for_dma+0x419/0x5c0
Nov 19 20:57:45 yuna kernel:  usb_hcd_submit_urb+0xa0/0xaa0
Nov 19 20:57:45 yuna kernel:  usb_start_wait_urb+0x65/0x100
Nov 19 20:57:45 yuna kernel: Map error: ffffd221000e02c0 ffff916fc336b4a0
Nov 19 20:57:45 yuna kernel: Map error: ffffd221000e02c0 ffff916fc336b4a0
Nov 19 20:57:45 yuna kernel: usb 1-1.1: new low-speed USB device number 3 using
xhci-hcd
Nov 19 20:57:45 yuna kernel: Map error: ffffd221000e02c0 ffff916fc336b4a0

...

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Alan Stern ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

 Attachment #305425|0                           |1

is obsolete| |

--- Comment #17 from Alan Stern ([email protected]) --- Created attachment 305444
--> https://bugzilla.kernel.org/attachment.cgi?id=305444&action=edit
Revised diagnostics

The ftrace doesn't help. You can't tell where the error occurs or which hub the function calls are for.

The patch wasn't quite right, so here is an updated version. Be sure to include the "cacheline tracking EEXIST, overlapping mappings aren't supported" line when you post the dmesg output.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #18 from Ferry Toth ([email protected]) ---
Hi Alan, would you know why your patches won't apply using git to v6.6? I fixed up manually. Results of Revised diagnostics attachment 305444 below:

------------[ cut here ]------------
DMA-API: dwc3 dwc3.0.auto: cacheline tracking EEXIST, overlapping mappings
aren't supported, len 4
WARNING: CPU: 0 PID: 7 at kernel/dma/debug.c:607 add_dma_entry+0x207/0x2c0
Modules linked in: rfcomm bnep iptable_nat snd_sof_nocodec spi_pxa2xx_platform
dw_dmac brcmfmac_wcc snd_sof_pci_intel_tng snd_sof_pci snd_sof_intel_atom
pwm_lpss>
CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.6.0-edison-acpi-standard+ #1
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
Workqueue: usb_hub_wq hub_event
RIP: 0010:add_dma_entry+0x207/0x2c0
Code: c8 00 00 00 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 fe a3 6a 00 48 89 c6
4c 89 e9 4c 89 e2 48 c7 c7 a8 1d 9a 99 e8 69 ac f5 ff <0f> 0b 48 85 db 74 1a 48
c7 >
RSP: 0018:ffffa4de00043ab0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff9c5f01376e80 RCX: 0000000000000027
RDX: ffff9c5f3e21c5c8 RSI: 0000000000000001 RDI: ffff9c5f3e21c5c0
RBP: 00000000ffffffff R08: ffffffff99d431e8 R09: 00000000ffffdfff
R10: ffffffff99c63200 R11: ffffffff99d13200 R12: ffff9c5f012375f0
R13: 0000000000000004 R14: 0000000000000206 R15: 00000000001eb8d2
FS:  0000000000000000(0000) GS:ffff9c5f3e200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f57691956b0 CR3: 000000003682e000 CR4: 00000000001006f0
Call Trace:
 <TASK>
 ? __warn+0x84/0x140
 ? add_dma_entry+0x207/0x2c0
 ? report_bug+0x199/0x1b0
 ? handle_bug+0x3c/0x70
 ? exc_invalid_op+0x18/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? add_dma_entry+0x207/0x2c0
 dma_map_page_attrs+0x10a/0x280
 usb_hcd_map_urb_for_dma+0x46f/0x650
 usb_hcd_submit_urb+0xa0/0xaa0
 ? kick_hub_wq+0x69/0xf0
 ? hub_activate+0x2c3/0x890
 ? usb_disable_remote_wakeup+0x34/0x70
 usb_start_wait_urb+0x65/0x100
 usb_control_msg+0xe5/0x150
 hub_ext_port_status+0x8a/0x1b0
 hub_event+0x1d1/0x18e0
 ? trace_hardirqs_on+0x21/0x90
 process_one_work+0x139/0x2f0
 worker_thread+0x2f4/0x400
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe6/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 </TASK>
---[ end trace 0000000000000000 ]---
DMA-API: Mapped at:
 debug_dma_map_page+0x6d/0x100
 dma_map_page_attrs+0x10a/0x280
 usb_hcd_map_urb_for_dma+0x46f/0x650
 usb_hcd_submit_urb+0xa0/0xaa0
 usb_start_wait_urb+0x65/0x100

Map error: 128857248 128857248 len 4
Map error: 128857248 128857248 len 4
usb 1-1.1: new low-speed USB device number 3 using xhci-hcd
Map error: 128857248 128857248 len 4
usb 1-1.1: New USB device found, idVendor=046d, idProduct=c03e, bcdDevice=20.00
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.1: Product: USB-PS/2 Optical Mouse
usb 1-1.1: Manufacturer: Logitech
input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:11.0/dwc3.0.auto/xhci-hcd.1.auto/usb1/1-1/1-1.1/1-1.1:1.0/0003:046D:C03E.0001/input/input1 hid-generic 0003:046D:C03E.0001: input,hidraw0: USB HID v1.10 Mouse [Logitech
USB-PS/2 Optical Mouse] on usb-xhci-hcd.1.auto-1.1/input0

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #19 from Alan Stern ([email protected]) --- Created attachment 305456
--> https://bugzilla.kernel.org/attachment.cgi?id=305456&action=edit
Diagnostic to find DMA overlap

The patches are prepared against a 6.6-rc3 tree (it hasn't been updated since then), so they might not match 6.6 exactly.

At least we're getting some good data from the patch:

...

The fact that the addresses and lengths agree indicate that the patch works right, and len = 4 means that the mapping error is indeed for the buffer containing the hub status data.

By the way, do you have any USB hubs besides this one on your system?

The next question is what other mapping already exists for that buffer? This next patch may be able to tell us. It's supposed to produce a second stack dump when the overlap occurs, for the call that created the first mapping.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #20 from Ferry Toth ([email protected]) --- It's not a conflict or so, I am getting (using qgit or cli):
git am --signoff /home/ferry/Downloads/dma-dbg.patch Patch format detection failed.

when I add --patch-format=mbox I get:
\Applying: @@ -, +, @@
fatal: empty ident name (for <>) not allowed

Never had this before.

I am testing on Intel Merrifield (Edison Arduino):

root@yuna:~# lsusb -t 
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 480M
        |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid,
1.5M

But root_hub 5000M is not available due to no phy.

With Diagnostic to find DMA overlap attachment 305456

------------[ cut here ]------------
DMA-API: dwc3 dwc3.0.auto: cacheline tracking EEXIST, overlapping mappings
aren't supported
WARNING: CPU: 0 PID: 105 at kernel/dma/debug.c:608 add_dma_entry+0x1fc/0x370
Modules linked in: rfcomm iptable_nat bnep snd_sof_nocodec spi_pxa2xx_platform

dw_dmac brcmfmac_wcc pwm_lpss_pci pwm_lpss snd_sof_pci_intel_tng intel_mrfld_pwrbtn snd_sof_pci snd_sof_intel_atom intel_mrfld_adc snd_sof dw_dmac_pci snd_sof_utils snd_sof_xtensa_dsp dw_dmac_core snd_intel_dspcfg snd_soc_acpi spi_pxa2xx_pci brcmfmac brcmutil hci_uart leds_gpio btbcm ti_ads7950 tun ledtrig_timer ledtrig_heartbeat mmc_block extcon_intel_mrfld sdhci_pci cqhci sdhci led_class mmc_core intel_soc_pmic_mrfld btrfs libcrc32c xor zlib_deflate zstd_compress raid6_pq

CPU: 0 PID: 105 Comm: kworker/0:3 Not tainted 6.6.0-edison-acpi-standard+ #1
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
Workqueue: usb_hub_wq hub_event
RIP: 0010:add_dma_entry+0x1fc/0x370
Code: ff 0f 84 80 01 00 00 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 e6 9d 6a 00
48 89 c6 4c 89 e2 48 c7 c7 10 21 5a b1 e8 94 a5 f5 ff <0f> 0b 48 85 db 74 1a 48
c7 c7 44 18 53 b1 e8 01 f9 fc ff 8b 73 4c
RSP: 0000:ffffb63c403fbab0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff908001374f00 RCX: 0000000000000027
RDX: ffff90803e21c5c8 RSI: 0000000000000001 RDI: ffff90803e21c5c0
RBP: 000000000019d4b5 R08: ffffffffb19431e8 R09: 00000000ffffdfff
R10: ffffffffb1863200 R11: ffffffffb1913200 R12: ffff908002124860
R13: 0000000000000001 R14: 0000000000000202 R15: 000000000019d4b5
FS:  0000000000000000(0000) GS:ffff90803e200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd58c003000 CR3: 0000000008096000 CR4: 00000000001006f0
Call Trace:
 <TASK>
 ? __warn+0x84/0x140
 ? add_dma_entry+0x1fc/0x370
 ? report_bug+0x199/0x1b0
 ? handle_bug+0x3c/0x70
 ? exc_invalid_op+0x18/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? add_dma_entry+0x1fc/0x370
 dma_map_page_attrs+0x10a/0x280
 usb_hcd_map_urb_for_dma+0x46f/0x650
 usb_hcd_submit_urb+0xa0/0xaa0
 ? kick_hub_wq+0x69/0xf0
 ? hub_activate+0x2c3/0x890
 ? usb_disable_remote_wakeup+0x34/0x70
 usb_start_wait_urb+0x65/0x100
 usb_control_msg+0xe5/0x150
 hub_ext_port_status+0x8a/0x1b0
 hub_event+0x1d1/0x18e0
 process_one_work+0x139/0x2f0
 ? __pfx_worker_thread+0x10/0x10
 worker_thread+0x2f4/0x400
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe6/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 </TASK>
---[ end trace 0000000000000000 ]---
DMA-API: Mapped at:
 debug_dma_map_page+0x6d/0x100
 dma_map_page_attrs+0x10a/0x280
 usb_hcd_map_urb_for_dma+0x46f/0x650
 usb_hcd_submit_urb+0xa0/0xaa0
 usb_start_wait_urb+0x65/0x100
DMA-API: Overlapped entry: 108342600 size 1
DMA-API: Mapped at:
 debug_dma_map_page+0x6d/0x100
 dma_map_page_attrs+0x10a/0x280
 usb_hcd_map_urb_for_dma+0x46f/0x650
 usb_hcd_submit_urb+0xa0/0xaa0
 hub_activate+0x29c/0x890

Map error: 108342608 108342608 len 4
Map error: 108342608 108342608 len 4
usb 1-1.1: new low-speed USB device number 3 using xhci-hcd
Map error: 108342608 108342608 len 4
usb 1-1.1: New USB device found, idVendor=046d, idProduct=c03e, bcdDevice=20.00
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.1: Product: USB-PS/2 Optical Mouse
usb 1-1.1: Manufacturer: Logitech
input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:11.0/dwc3.0.auto/xhci-hcd.1.auto/usb1/1-1/1-1.1/1-1.1:1.0/0003:046D:C03E.0001/input/input1 hid-generic 0003:046D:C03E.0001: input,hidraw0: USB HID v1.10 Mouse [Logitech
USB-PS/2 Optical Mouse] on usb-xhci-hcd.1.auto-1.1/input0

I also notice now on unplugging the mouse:

Map error: 108342608 108342608 len 4
usb 1-1.1: USB disconnect, device number 3
Map error: 108342608 108342608 len 4
Map error: 108342608 108342608 len 4
Map error: 108342608 108342608 len 4
Map error: 108342608 108342608 len 4
Map error: 108342608 108342608 len 4

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #21 from Andy Shevchenko ([email protected]) --- Looks like read mapping is bigger than 8, I think it might have a cache line alignment requirement. But I have knowledge of USB core code, I believe Alan knows much better what's going on there.

Btw, I don't see USB using
https://elixir.bootlin.com/linux/v6.7-rc2/C/ident/dma_get_cache_alignment API (except the only DWC2 case).

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #22 from Andy Shevchenko ([email protected]) --- Also there is dma_kmalloc_size_aligned() which might help.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Alan Stern ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected],
                   |                            |[email protected]

--- Comment #23 from Alan Stern ([email protected]) --- +Christoph Hellwig (because I am not an expert on kmalloc and cache line alignment)

Ferry: Sorry about the malformed patches. The bad line was added automatically by Quilt (I don't know why). If I add any more patches, I'll try to remember to remove that bogus line first.

Andy: There are two mappings in question here, both of them are reads, neither is larger than 8 bytes, and neither has a cache line alignment requirement (other than the general restriction that on architectures with non-cache-coherent DMA -- i.e., not x86 -- different allocations should belong to different cache lines).

The first mapping is 1 byte long (at the start of the 8-byte-long hub->buffer allocated near the beginning of hub_configure() in drivers/usb/core/hub.c) and the second is 4 bytes long (for hub->status, allocated just afterward). The physical addresses and sizes of the mappings, as shown in the log, are:

hub->buffer: 108342600 size 1
hub->status: 108342608 size 4

Obviously they lie in the same cache line, which is what triggers the DMA debugging error. But equally obviously, on x86 or other architectures with cache-coherent DMA, there is nothing wrong with them.

Incidentally,

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #24 from Alan Stern ([email protected]) --- Sorry, submitted the update too soon. I meant to add:

Incidentally, the check for overlapping DMA mappings does not take into account the possibility that a mapping can extend over several cache lines. Maybe this wasn't deemed important enough to check for.

But in any case, it seems clear that on x86 there shouldn't be anything wrong with allowing several different mappings to refer to the same cache line.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #25 from Andy Shevchenko ([email protected]) --- I'm not sure I understand 'u8 (*buffer)[8]' in the data struct, sounds like 8 pointers, so the side has to be 32/64 bytes. As for the next field, status, it's a pointer and again 4/8 bytes. I believe we are talking about x86_64 case, so I fail to see how 1 and 4 map to the struct usb_hub fields. Is the len in your debug patches is in "long"s units? Then it makes sense if the status is mapped first (1 long) followed by 4 (out of 8) URB buffer pointers.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #26 from Alan Stern ([email protected]) --- "u8 (*buffer)[8]" means that buffer is a pointer to an array of 8 u8's, NOT an array of 8 pointers to u8. The latter would be written as "u8 *(buffer[8])" or "u8 *buffer[8]". C's syntax is notoriously difficult to understand when talking about arrays of pointers and pointers to arrays; you have to parse the declaration from the inside out and you may need to know that postfix "[]" has higher binding precedence than prefix "*".

1 and 4 don't map to anything; they are the _lengths_ of the DMA mappings. That is, the first mapping is 1 byte long and the second mapping is 4 bytes
long: These are lengths in bytes, not in longs.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #27 from Andy Shevchenko ([email protected]) --- Yeah, I got it, so the problematic one (that triggers a warning) is this line

  ret = get_port_status(hub->hdev, port1, &hub->status->port, type, len);

where port is 8 bytes, but len = 4 as we asked for non-extended status.

Which line maps the DMA?

```
} else {
        urb->transfer_dma = dma_map_single(
                        hcd->self.sysdev,
                        urb->transfer_buffer,
                        urb->transfer_buffer_length,
                        dir);
```

This one?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #28 from Alan Stern ([email protected]) --- Yes, that one.

The issue of "which mapping is the problematic one" is more or less irrelevant. The warning is issued when the second mapping is created. The order of the two mappings doesn't matter, just the fact that they refer to the same cache line.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #29 from Ferry Toth ([email protected]) --- (In reply to Andy Shevchenko from comment #25)

Yes. But I just checked and the same happens with i686 kernel (on same platform).

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #30 from Ferry Toth ([email protected]) --- So I checked and:

root@yuna:~# cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
64

So I just simply added to your debug patches:

index 0ff47eeffb49..ba5864b23aed 100644
@@ -1420,7 +1420,7 @@ static int hub_configure(struct usb_hub *hub,
        unsigned full_load;
        unsigned maxchild;
 
-       hub->buffer = kmalloc(sizeof(*hub->buffer), GFP_KERNEL);
+       hub->buffer = kmalloc(64, GFP_KERNEL);
        if (!hub->buffer) {
                ret = -ENOMEM;
                goto fail;

and the problem disappears.
But then, why Comment 15 can Alan not reproduce this?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #31 from Alan Stern ([email protected]) ---
I don't know why my local test didn't reproduce the problem -- and I haven't tried to find out what's happening. My best guess is that the allocations of hub->buffer and hub->status end up (by random chance) being non-adjacent, so they aren't in the same cache line. But I haven't even run the test patches attached to this bug report.

Regardless, changing the allocation size to 64 merely hides the problem. The real problem is that the DMA debugging code is wrong and needs to be fixed. It should not complain about two different mappings of the same cache line on x86, unless the mappings actually overlap.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #32 from Ferry Toth ([email protected]) ---
By changing the allocation I just wanted to close the loop and prove this is the trigger.

And maybe on other platforms than x86 an actual issue? What do you think of Andy's suggestion to use dma_kmalloc_size_aligned()?

I still find it strange that the issue does not reproduce for you. I have built each kernel since this issue was introduced, with multiple compiler versions, x86_64/i686 and it happens 100% of the cases. Could there be another related CONFIG?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #33 from Alan Stern ([email protected]) ---
It should not be necessary to use dma_kmalloc_size_aligned(). These allocations don't need any special alignment; they just need to be in different cache lines on some architectures. Isn't this what ARCH_DMA_MINALIGN and ARCH_KMALLOC_MINALIGN are supposed to take care of (see include/linux/slab.h)?

I'll try doing a little more testing to find out why the issue does not show up on my computer.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Alan Stern ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

 Attachment #305444|0                           |1
        is obsolete|                            |
 Attachment #305456|0                           |1
        is obsolete|                            |

--- Comment #34 from Alan Stern ([email protected]) --- Created attachment 305473
--> https://bugzilla.kernel.org/attachment.cgi?id=305473&action=edit
Revised (again) diagnostics

I revised the test patch slightly. Now the addresses are printed in hex, as they should have been all along. Also, there's a line to print out the physical addresses pointed to by hub->buffer and hub->status when a new hub is configured. Here's the log for plugging in a hub, then plugging a mouse into the hub:

[   32.757399] usb 1-1: new high-speed USB device number 5 using xhci_hcd
[   32.886200] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608,
bcdDevice= 9.01
[   32.886444] usb 1-1: New USB device strings: Mfr=0, Product=1,
SerialNumber=0
[   32.886631] usb 1-1: Product: USB2.0 Hub
[   32.889566] hub 1-1:1.0: USB hub found
[   32.889813] usb 1-1: hub buffer at 100e71818, status at 100e71610
[   32.890499] hub 1-1:1.0: 4 ports detected
[   42.761267] usb 1-1.3: new low-speed USB device number 6 using xhci_hcd
[   42.833935] kauditd_printk_skb: 101 callbacks suppressed
[   42.844775] usb 1-1.3: New USB device found, idVendor=093a, idProduct=2510,
bcdDevice= 1.00
[   42.844841] usb 1-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[   42.844890] usb 1-1.3: Product: USB OPTICAL MOUSE
[   42.844933] usb 1-1.3: Manufacturer: PIXART
[   42.851150] input: PIXART USB OPTICAL MOUSE as
/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:093A:2510.0009/input/input10
[   42.851585] hid-generic 0003:093A:2510.0009: input,hidraw8: USB HID v1.11

Mouse [PIXART USB OPTICAL MOUSE] on usb-0000:00:14.0-1.3/input0

The cache line size on this computer is 64 bytes, same as yours. As you can see, hub->buffer and hub->status were allocated in different cache lines, so the DMA debugging routine did not detect an overlap. That's why I didn't get any error messages.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #35 from Alan Stern ([email protected]) ---
So as most of the people subscribing to this bug have seen from the email discussion, it looks like the bug ultimately lies in the alignment of kmalloc() buffers and it probably will be fixed with a kernel patch.

Equally important, however, is the question of why the people experiencing this problem turned on CONFIG_DMA_API_DEBUG in the first place. That setting is meant only for kernel testing and it drastically reduces performance. Redhat certainly should not enable it in any of their distribution kernels (and in fact it is not set in my copy of Fedora 38).

Andrew, Ferry, any comments?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #36 from Ferry Toth ([email protected]) --- Your latest patch gives me:

root@yuna:~# journalctl -k | grep "hub buffer"
kernel: usb usb1: hub buffer at 6e1cda0, status at 6e1cda8
kernel: usb usb2: hub buffer at 6e1ce20, status at 6e1ce28
kernel: usb 1-1: hub buffer at 8001380, status at 8001388

The first 2 lines are for the root hubs.

In my case on Intel Edison-Arduino the distribution is Yocto generated. The platform is especially suited to attach custom hardware, iio devices, arduino shields and the like, as you have direct access to gpios, i2c, spi, hsu. So CONFIG_DMA_API_DEBUG was enabled to help debug device drivers.

I have to admit I never realised it to be an expensive option. And certainly didn't expect to find bugs in DMA_API_DEBUG itself or kmalloc(). I'll turn that into an optional thing with a comment on possible side effects.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #37 from Alan Stern ([email protected]) --- Okay. On an Intel Edison-Arduino the slowdown won't be as dramatic as on a large system doing high-bandwidth I/O. But you'll still want to avoid it if you can.

Have you tried testing the patch posted in the email thread?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #38 from Ferry Toth ([email protected]) --- With Catalin Marinas's suggestion "force the kmalloc() min align to cache_line_size()" + attachment 305473

root@yuna:~# journalctl -k | grep hub  
kernel: usbcore: registered new interface driver hub
kernel: hub 1-0:1.0: USB hub found
kernel: usb usb1: hub buffer at 71c7180, status at 71c71c0
kernel: hub 1-0:1.0: 1 port detected
kernel: hub 2-0:1.0: USB hub found
kernel: usb usb2: hub buffer at 71c79c0, status at 71c7a00
kernel: hub 2-0:1.0: 1 port detected
kernel: hub 1-1:1.0: USB hub found
kernel: usb 1-1: hub buffer at 65b36c0, status at 6639340
kernel: hub 1-1:1.0: 7 ports detected

and stack trace goes away.
IOW the 2 root hub kmalloc() are now also aligned to the cache line size, even though these never triggered the stack trace. Strange: hub's status is aligned far away from hub buffer.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #39 from Andy Shevchenko ([email protected]) --- @Alan, others, so what is the status of affairs? What's the conclusion? I still get the warning almost every time I boot my boards.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #40 from Andy Shevchenko ([email protected]) --- Also note, the boards are not limited to Intel Merrifield based ones, I have the same stacktrace on different Intel SoCs, like Apollo Lake (Joule).

[    0.145195] smpboot: CPU0: Intel(R) Atom(TM) Processor T5700 @ 1.70GHz
(family: 0x6, model: 0x5c, stepping: 0x2)
...
[    2.740381] ------------[ cut here ]------------
[    2.741675] DMA-API: xhci_hcd 0000:00:15.0: cacheline tracking EEXIST,
overlapping mappings aren't supported
[    2.744345] WARNING: CPU: 0 PID: 64 at kernel/dma/debug.c:607

add_dma_entry+0x219/0x350

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Guenter Roeck ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #41 from Guenter Roeck ([email protected]) --- This problem may only be seen with DMA API debugging active, but it is a nuisance if that debugging is enabled during testing.

Would a workaround such as the following be acceptable upstream ?

index 145787c424e0..a396f81d0322 100644
@@ -31,6 +31,7 @@
 #include <linux/random.h>
 #include <linux/pm_qos.h>
 #include <linux/kobject.h>
+#include <linux/cache.h>
 
 #include <linux/bitfield.h>
 #include <linux/uaccess.h>

@@ -1437,7 +1438,8 @@ static int hub_configure(struct usb_hub *hub,
        unsigned full_load;
        unsigned maxchild;
 
-       hub->buffer = kmalloc(sizeof(*hub->buffer), GFP_KERNEL);
+       hub->buffer = kmalloc(max_t(size_t, sizeof(*hub->buffer),
+                                   cache_line_size()), GFP_KERNEL);
        if (!hub->buffer) {
                ret = -ENOMEM;
                goto fail;

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #42 from Alan Stern ([email protected]) ---
In theory the problem could arise from any two kmalloc allocations, not just the ones done by the USB hub driver. It would be better to fix this in the MM core or in Kconfig: Set the minimal allocation alignment to the cache-line size whenever CONFIG_DMA_API_DEBUG is enabled.

Would that be acceptable?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #43 from Guenter Roeck ([email protected]) --- Like this ?

index d5a8ab98035c..7b38a4bba9a5 100644
@@ -507,6 +507,19 @@ static inline bool kmem_dump_obj(void *object) { return

false; }
#endif
#endif

+/*
+ * Align memory allocations to cache lines if DMA API debugging is active
+ * to avoid false positive DMA overlapping error messages. .
+ */
+#ifdef CONFIG_DMA_API_DEBUG
+#ifndef ARCH_KMALLOC_MINALIGN
+#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
+#elif ARCH_KMALLOC_MINALIGN < L1_CACHE_BYTES
+#undef ARCH_KMALLOC_MINALIGN
+#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
+#endif
+#endif
+

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #44 from Alan Stern ([email protected]) --- That seems reasonable.

Some people may object, on the grounds that turning on debugging should not affect the way the kernel (memory allocation in particular) behaves -- otherwise what you're debugging isn't the same as what normally happens. But given the way the DMA API debugging is set up, I don't see any alternative.

Can somebody test this patch?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Jeff Kirsher ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #45 from Jeff Kirsher ([email protected]) ---
I was able to reproduce the issue and I tested your patch on a 6.16.12 kernel, as well as a 6.8.0 kernel. You patch resolved the issue. I was able to test this fix for over 4 months now (sorry for the delayed response).

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #46 from Andy Shevchenko ([email protected]) --- May somebody submit a formal patch, please?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #47 from Guenter Roeck ([email protected]) ---
I (and Google, for that matter) long since went beyond that after the above feedback ("Equally important, however, is the question of why the people experiencing this problem turned on CONFIG_DMA_API_DEBUG in the first place. That setting is meant only for kernel testing and it drastically reduces performance.").

For context, we don't enable CONFIG_DMA_API_DEBUG in production images. We enable it in test images to catch problems which are only caught in debug images. Getting false positives in such images doesn't help and hides real problems.

So we gave up trying to fix the problem in the upstream kernel and implemented a (downstream) workaround which excludes the "hub" and "xhcd_hcd" drivers from DMA cacheline tracking. That may not be perfect, but it does the trick for us.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #48 from Andy Shevchenko ([email protected]) --- So, is there any consensus which solution should somebody try as a new attempt to fix this?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #49 from Alan Stern ([email protected]) --- As far as I'm concerned, the patch in comment #43 seems to be the most generally applicable solution. If anyone has any better ideas, they should speak up.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #50 from Andy Shevchenko ([email protected]) --- Thanks, Alan. Guenter, can you submit a formal patch perhaps? It seems you have a good justification for it as stated in the comment #47.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Mikhail ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
                   |                            |m

--- Comment #51 from Mikhail ([email protected]) --- Created attachment 309769
--> https://bugzilla.kernel.org/attachment.cgi?id=309769&action=edit
dma_cacheline_eexist_repro.mod.c

I hit this exact warning on 7.0-rc5 with an ASUS USB Audio device (0b05:1a5c) on AMD B650E (ROG STRIX B650E-I) + xhci_hcd 0000:0c:00.0. Same stack trace through snd_usb_ctl_msg -> usb_control_msg -> usb_hcd_map_urb_for_dma -> dma_map_phys -> add_dma_entry -> EEXIST.

I tested Guenter's patch from comment #43 (ARCH_KMALLOC_MINALIGN = L1_CACHE_BYTES when CONFIG_DMA_API_DEBUG) and can confirm it fixes the issue.

I also wrote a kernel module reproducer that triggers the bug reliably on demand, without needing to wait for a specific USB device to be plugged in during boot. The module does exactly what hub_configure()
does: two kmalloc(8) allocations back-to-back, then DMA-maps both. On x86_64 with ARCH_KMALLOC_MINALIGN=8, they land in the same 64-byte cacheline within ~50 attempts, triggering the EEXIST warning.

Before fix:
dma_repro: pair 53: buf_a=ffff8881c8f9eb80 buf_b=ffff8881c8f9eba0

             -- SAME cacheline 119793582!

DMA-API: cacheline tracking EEXIST, overlapping mappings aren't
supported

After fix (ARCH_KMALLOC_MINALIGN >= L1_CACHE_BYTES):
dma_repro: no same-cacheline pair found in 64 attempts
(ARCH_KMALLOC_MINALIGN may already be >= cache_line_size)

I can submit a formal patch based on Guenter's fix if nobody objects.

Reproducer module source attached.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

--- Comment #52 from Guenter Roeck ([email protected]) --- #51: ounds good. I'd suggest to go ahead.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=215740

Andy Shevchenko ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |PATCH_ALREADY_AVAILABLE

--- Comment #53 from Andy Shevchenko ([email protected]) --- (In reply to Guenter Roeck from comment #52)

Agree. I close this for now since we have a compromise solution publicly available.
https://lore.kernel.org/all/[email protected]/

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.