From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77D75C36010 for ; Tue, 1 Apr 2025 16:43:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31854280004; Tue, 1 Apr 2025 12:43:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29EEB280001; Tue, 1 Apr 2025 12:43:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F421280004; Tue, 1 Apr 2025 12:43:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D9A46280001 for ; Tue, 1 Apr 2025 12:43:43 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3C36380590 for ; Tue, 1 Apr 2025 16:43:44 +0000 (UTC) X-FDA: 83286046368.27.5E1EC0C Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf15.hostedemail.com (Postfix) with ESMTP id B4AA5A0002 for ; Tue, 1 Apr 2025 16:43:42 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf15.hostedemail.com: domain of cmarinas@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743525822; a=rsa-sha256; cv=none; b=zncx8S+3KFWwk6sBpIBayFB8rH6Vy7K4ruLlz6CbVgJ4MJHTjHWmSND9T99mU/m2GPnQ4Q H0ebb8Nb3Tgbpr8FvsNqjH5gXWMiaKUf3TuDdHa/K/z9XKnJvX1BlP/cI1Dwx6kRVB+AeH 5zzdkiHnxBp4tk25TKOjXKxSGpYO5XU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf15.hostedemail.com: domain of cmarinas@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743525822; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=shn0tnN+wBrIjE3dOep3eH6eMsEq/Sb0KIGYTxFfN5A=; b=kQjGiMW/NvgC5KEwyynkdw6oxZm5cUXY6FuwDL8gJ09iynW4lS3MUtmIxSA9WsUjN725OV OFlmfSgHF/muyQbikVhgelJGCq4/9ryKQt1sutX06bP8RkIDqbBShGmKusm9fhzlg4Iar5 REBytsqzOmJEyTdvqWqtLZsZmSVViyw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 226EB6112E; Tue, 1 Apr 2025 16:43:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D942CC4CEE4; Tue, 1 Apr 2025 16:43:39 +0000 (UTC) Date: Tue, 1 Apr 2025 17:43:37 +0100 From: Catalin Marinas To: John Ernberg Cc: Peter Chen , Pawel Laszczak , Roger Quadros , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "linux-usb@vger.kernel.org" , "imx@lists.linux.dev" , Jonas Blixt Subject: Re: [PATCH v7 00/17] mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8 Message-ID: References: <20230612153201.554742-1-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B4AA5A0002 X-Stat-Signature: 5m4r6w1gmmmd6rufzt6jjksm6umabmsz X-HE-Tag: 1743525822-691498 X-HE-Meta: U2FsdGVkX18+/M8RjZQMIn9bLyeniCwNmowW8UEeyQgLzDiVrx2kqpcOav2LcsLObOc978XBnqrii/jPCdfz8F1LCXUSrnUbpYPMZzFI+iaXKoTuJPO4BNrhbhW6FVg91gfyhuBFMitW/DsBayWD/n7SFQRWR52hc8SbPmv8iLj0KAV97hNti6AQuKdRSLw2f/n2pVczZt+Z307UtZypaz/T6eYgeRygoRaqhy+a7mEYt8s8U3JM0pBCgx/WXsbu/2in1Fjl30kHtnOf24Jkn9TvcylSw/46i1G7hznhcO4fSAXarnHBMCG24EW9EZUfM0tEpEJY+ZqjgiyisLd31knJyA/yaWdwwa2Wim1zul8wEke41QZNF339ykuFOb9nDEH/FB2R5RAqR6colLz7vIAE99M5osuC21i+076DY+tmGo2kEK7Pb+Mdpl2lkGf+/DbiqQlfqrRESQIVfFTtBQD6r2THKuezBfvwNByWc7l1Zv2xpgQxqRPyVo5jZ503FEDIAlo857v92ra07ghPWKp4hVyzdpJbkYv86jUZVPkaqS0/Sj+5xcNH5s1VTpBfKvTgOW3Ur0Ng581kwK8WgvMPqFlr3C3Jv8TCVtwAFLebhtKVbyZR6DpWzv4cJl7EEThc2fnem1edEFFnCnBe2PZ+XBoQR8EnRtEg8QVLokrsf2sH+xtsWquQUCANiGM1jbZ9xa4QzbqlAp8yCdE5qlKVolTAVkqjW1x05fWVYWYBkcb6BcId2Iq28eAVU+QLXfGhdob/EPaqA7fTRgd5wBK87NWiJSeuHeRyBGPXuIYJ4p5II/TRO80kEkuFY+kXKDLaTZ2t+JHmeGOtBINrBZZuhO/LLvvPb2NePyp+dOmaIAUSFaLliB4aAszy6Q92cdAoB8IBTYcYwynAHL+iG8NkqrXcnggcdKDK6YT1+ByQEN0tD1s2bp33845cJXJF6jX1iZ+x54eKsev+djm 5nkAVPDz hDHfiG5jzmaDvlrp0SOpvig2IBatvnTu1OvsRn2sdyv6vXquZXUZ8rb589JDWxZrzgi5d3sj+pGXMQ8MDjQwzZ9haHhFoMK8ZNY7IlGwTO5GSDgFkvmygEcH1PcKBb9vSII6Bi+RLDFQOTTNOEQTjz8l/1IOcuoZGr6PRz0tlRTmwbFPi+E2fzQLzvL6jSjPHK+WSSaT76j9UZwIGfkk9zMOFsnqRsXC9IQEjF43NExDJqW3/jtMSpVqqLRJA/Yivmbs5+S4kBfB6VkQHqcktDd0SlnWyfXiNx23DegXN+GzpStL4zoK98/xEbDxxbI1Zr8lLCQxXPdewgxEfBGqBfSvVh+vgVRoA78AwGw1hZc0hi7cwQDvkovxHALDszml4/GAe51otUcNwagKZC/++vkdQv+CCYXECOgnLrmpefJfTKln8qTvxR0NHpmeXMKggA9FaCdyeButxFN0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Mar 28, 2025 at 04:41:05PM +0000, John Ernberg wrote: > On 6/12/23 5:31 PM, Catalin Marinas wrote: > > 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 > > [...] > 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. I'm not aware of any recent fix for this, so I doubt testing a newer kernel would make a difference. > 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. > > 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. I'm not really familiar with this area. My only drivers/usb/ change related to ARCH_KMALLOC_MINALIGN was commit 075efe7c1656 ("drivers/usb: use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN"). I wouldn't be surprised if I missed other things that rely on the kmalloc() alignment rather than explicit macros. > 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. It might be worth enabling CONFIG_DMA_API_DEBUG to see if it complains. I lost myself in the call paths on how read_buf gets populated. In principle, the DMA API should handle bouncing (swiotlb) even if you pass it a buffer smaller than the required alignment Random shot, untested and not an actual fix but some ideas for debugging: ------------------8<------------------------------- diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 44179f4e807f..06d5f9bfef75 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -2024,7 +2024,7 @@ static int __usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8 reqtype, cmd, reqtype, value, index, size); if (size) { - buf = kmalloc(size, GFP_NOIO); + buf = kmalloc(ALIGN(size, dma_get_cache_alignment()), GFP_NOIO); if (!buf) goto out; } @@ -2171,12 +2171,13 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype, goto fail; if (data) { - buf = kmemdup(data, size, GFP_ATOMIC); + buf = kmalloc(ALIGN(size, dma_get_cache_alignment()), GFP_ATOMIC); if (!buf) { netdev_err(dev->net, "Error allocating buffer" " in %s!\n", __func__); goto fail_free_urb; } + memcpy(buf, data, size); } req = kmalloc(sizeof(struct usb_ctrlrequest), GFP_ATOMIC); diff --git a/drivers/usb/cdns3/cdnsp-mem.c b/drivers/usb/cdns3/cdnsp-mem.c index 97866bfb2da9..226ac7af6511 100644 --- a/drivers/usb/cdns3/cdnsp-mem.c +++ b/drivers/usb/cdns3/cdnsp-mem.c @@ -45,6 +45,7 @@ static struct cdnsp_segment *cdnsp_segment_alloc(struct cdnsp_device *pdev, return NULL; } + max_packet = ALIGN(max_packet, dma_get_cache_alignment()); if (max_packet) { seg->bounce_buf = kzalloc(max_packet, flags | GFP_DMA); if (!seg->bounce_buf) ------------------8<------------------------------- Even without the above, my reading of the code is that it is safe since the buffers eventually end up in dma_map_single() which would do bouncing via an aligned buffer. Try to track down call paths from smsc95xx_read_reg() and smsc95xx_write_reg_async() to usbnet_{read,wrote}_cmd* etc. and see how the DMA transfers happen, whether it's missing some dma_map_* call. The dma_map_* bouncing logic relies on the size, see dma_kmalloc_needs_bounce(). Is there an iommu between the usb host controller and memory? The iommu code should do similar bouncing but it's had minimal testing. -- Catalin