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

[John Ernberg <john.ernberg@actia.se>]

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.

> 
>>
>> 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