[PATCH v7 00/17] mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8

[Frank Li]

On Mon, Mar 31, 2025 at 08:02:20AM +0000, John Ernberg wrote:
> Hi Frank,
>
> On 3/28/25 8:38 PM, Frank Li wrote:
> > On Fri, Mar 28, 2025 at 04:41:05PM +0000, John Ernberg wrote:
> >> On 6/12/23 5:31 PM, Catalin Marinas wrote:
> >>> Hi,
> >>>
> >>> That's v7 of the series reducing the kmalloc() minimum alignment on
> >>> arm64 to 8 (from 128). There's no new/different functionality, mostly
> >>> cosmetic changes and acks/tested-bys.
> >>>
> >>> Andrew, if there are no further comments or objections to this version,
> >>> are you ok to take the series through the mm tree? The arm64 changes are
> >>> fairly small. Alternatively, I can push it into linux-next now to give
> >>> it some wider exposure and decide whether to upstream it when the
> >>> merging window opens. Thanks.
> >>>
> >>> The updated patches are also available on this branch:
> >>>
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux devel/kmalloc-minalign
> >>>
> >>
> >> (I trimmed the recipients and added linux-usb and imx mailing list, +
> >> cdns3 maintainers)
> >>
> >> Hi Catalin, lists,
> >>
> >> Seen on Linux 6.12.20, it is not trivial for us to test later kernels so
> >> if the issue is potentially fixed we are more than happy to cherry-pick
> >> the potential fixes and give them a go.
> >>
> >> Having an SMSC9512 (smsc95xx) USB Ethernet/Hub chip attached to the armv8
> >> SoC iMX8QXP over the Cadence USB3 USB2 interface (cdns3-imx) will since
> >> the patch set at [0] cause random interrupt storms over the SMSC9512 INT
> >> EP.
> >
> > Do you know where buy SMSC9512 USB Ethernet/Hub?
>
> A quick google search didn't find my any dongles that are still
> available, however the SMSC 95xx series of chips used to be popular in
> USB to Ethernet dongles.
>
> Otherwise they are made by Microchip today, any variant of the SMSC 95xx
> should be able to trigger the problem.

I worry about that xhci have similar issue with gadget dma.

	/*
         * In versions preceding DEV_VER_V2, for example, iMX8QM, there exit the bugs
         * in the DMA. These bugs occur when the trb_burst_size exceeds 16 and the
         * address is not aligned to 128 Bytes (which is a product of the 64-bit AXI
         * and AXI maximum burst length of 16 or 0xF+1, dma_axi_ctrl0[3:0]). This
         * results in data corruption when it crosses the 4K border. The corruption
         * specifically occurs from the position (4K - (address & 0x7F)) to 4K.
         *
         * So force trb_burst_size to 16 at such platform.
         */

Let try reduce AXI burst len to help your case.

diff --git a/drivers/usb/cdns3/host.c b/drivers/usb/cdns3/host.c
index f0df114c2b53b..200166395c09d 100644
--- a/drivers/usb/cdns3/host.c
+++ b/drivers/usb/cdns3/host.c
@@ -24,6 +24,7 @@
  * with Cadence CDNSP dual-role controller.
  */
 #define XECP_PORT_CAP_REG      0x8000
+#define XECP_AXI_CTRL0         0x8034
 #define XECP_AUX_CTRL_REG1     0x8120

 #define CFG_RXDET_P3_EN                BIT(15)
@@ -121,7 +122,9 @@ static int __cdns_host_init(struct cdns *cdns)
        if (hcd)
                cdns->xhci_regs = hcd->regs;

-       return 0;
+       writel(0x1, cdns->xhci_regs + XECP_AXI_CTRL0);
+
+       return 0;

Frank

>
> >
> >>
> >> The reason for the storm is that the async URBs queued at [1] right before
> >> the interrupt configuration [2] in the driver.
> >> With [0] applied, those async URBs are likely clobbering any URB located
> >> after them in memory somewhere in the xhci memory space.
> >> The memory corruption only happens if there is more than one URB in the
> >> queue at the same time, making these async URBs a good trigger of the
> >> problem.
> >> If we force those URBs to be sync or use the hack inlined below, the
> >> problem goes away.
> >>
> >> The content of read_buf in the interrupt configuration read at [2] looks
> >> to be the lo-part of a pointer +-20 bytes distance from the pointers
> >> present in the async URBs queued from [1] when we dumped the URB structures
> >> instead of the expected register contents.
> >>
> >> Attached are 3 usbmon captures, with some annotations, which we thought
> >> might contain useful hints.
> >>
> >> * usb-annotated-bad.pcapng shows the URB that will get clobbered is queued
> >>     at position 280, and completes at 282.
> >>
> >> * usb-annotated-good.pcapng shows the URB that gets clobbered in the bad
> >>     case is queued at position 282 and completes at 283.
> >>
> >> The above captures are from a kernel where the hack has not been applied.
> >>
> >> * usb-annotated-hackfix.pcapng shows the URB that gets clobbered in the
> >>     bad case is queued at position 238 and completes at 240.
> >
> > Maillist have not attachment. Can you send it to me directly?
>
>
> The linux-usb mailing list picked up the attachments.
>
> https://lore.kernel.org/linux-usb/Z+b6qrgXz%2FNTOs5r@lizhi-Precision-Tower-5810/T/#t
>
> Best regards // John Ernberg