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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6B3FC4338F for ; Wed, 25 Aug 2021 04:39:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6E32561246 for ; Wed, 25 Aug 2021 04:39:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6E32561246 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E65D26B006C; Wed, 25 Aug 2021 00:39:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E16706B0071; Wed, 25 Aug 2021 00:39:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDDDB8D0001; Wed, 25 Aug 2021 00:39:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id AD4B76B006C for ; Wed, 25 Aug 2021 00:39:11 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 331251818981D for ; Wed, 25 Aug 2021 04:39:11 +0000 (UTC) X-FDA: 78512348502.24.7CF5521 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP id BFB92F0003A1 for ; Wed, 25 Aug 2021 04:39:10 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 9564761246; Wed, 25 Aug 2021 04:39:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629866346; bh=DyJlqtTO+nFr0UnDA22UPSMLbTJ+DzvuMl9//OXkwzE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qPEay1hYiUr55ZMZUrxsSndXmclPRr9OIYk4pCIV24HBrV0SgRNe8QBlZ6yKyfnyN L5dT0c9rHRIEHLS29zCHtSti+dzEcrBncirZiitQofLip9UDhzN8tDcrL1KzJ7T4P0 EW9FkMJr44oatqBJJ8QrDEOxAcAvB1hdmGMt2Yx3mKMD6xCvG/zK1AKBkzqPRjwca0 XuTj4wwcckO5axQG9XVj0Ftv5H+hwMQVTy/+KdZ095uuGf5UE5m+tbh0uAjglMPIY+ vgnCloEWZX1T2HJKlhGcZ2Gx/G5EUPvEZ7O1dGgeUemqWQtLbjlP0FSI48ArNgoyz+ D4AihaLgGRUnA== Date: Wed, 25 Aug 2021 07:39:00 +0300 From: Mike Rapoport To: Alex Bee Cc: Catalin Marinas , Will Deacon , Andrew Morton , Anshuman Khandual , Linux Kernel Mailing List , linux-mm@kvack.org, Linux ARM , Robin Murphy Subject: Re: [BUG 5.14] arm64/mm: dma memory mapping fails (in some cases) Message-ID: References: <20210824173741.GC623@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qPEay1hY; spf=pass (imf17.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: BFB92F0003A1 X-Stat-Signature: 88e8bzipj6tudqqsfh9ezinub4xa1q5c X-HE-Tag: 1629866350-929846 Content-Transfer-Encoding: quoted-printable 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: On Tue, Aug 24, 2021 at 10:14:01PM +0200, Alex Bee wrote: > Hi Mike, >=20 > thanks for your reply >=20 > Am 24.08.21 um 20:28 schrieb Mike Rapoport: > > On Tue, Aug 24, 2021 at 06:37:41PM +0100, Catalin Marinas wrote: > > > Hi Alex, > > >=20 > > > Thanks for the report. > > >=20 > > > On Tue, Aug 24, 2021 at 03:40:47PM +0200, Alex Bee wrote: > > > > it seems there is a regression in arm64 memory mapping in 5.14, s= ince it > > > > fails on Rockchip RK3328 when the pl330 dmac tries to map with: > > > >=20 > > > > [=A0=A0=A0 8.921909] ------------[ cut here ]------------ > > > > [=A0=A0=A0 8.921940] WARNING: CPU: 2 PID: 373 at kernel/dma/mappi= ng.c:235 dma_map_resource+0x68/0xc0 > > > > [=A0=A0=A0 8.921973] Modules linked in: spi_rockchip(+) fuse > > > > [=A0=A0=A0 8.921996] CPU: 2 PID: 373 Comm: systemd-udevd Not tain= ted 5.14.0-rc7 #1 > > > > [=A0=A0=A0 8.922004] Hardware name: Pine64 Rock64 (DT) > > > > [=A0=A0=A0 8.922011] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO B= TYPE=3D--) > > > > [=A0=A0=A0 8.922018] pc : dma_map_resource+0x68/0xc0 > > > > [=A0=A0=A0 8.922026] lr : pl330_prep_slave_fifo+0x78/0xd0 > > > > [=A0=A0=A0 8.922040] sp : ffff800012102ae0 > > > > [=A0=A0=A0 8.922043] x29: ffff800012102ae0 x28: ffff000005c94800 = x27: 0000000000000000 > > > > [=A0=A0=A0 8.922056] x26: ffff000000566bd0 x25: 0000000000000001 = x24: 0000000000000001 > > > > [=A0=A0=A0 8.922067] x23: 0000000000000002 x22: ffff000000628c00 = x21: 0000000000000001 > > > > [=A0=A0=A0 8.922078] x20: ffff000000566bd0 x19: 0000000000000001 = x18: 0000000000000000 > > > > [=A0=A0=A0 8.922089] x17: 0000000000000000 x16: 0000000000000000 = x15: 0000000000000000 > > > > [=A0=A0=A0 8.922100] x14: 0000000000000277 x13: 0000000000000001 = x12: 0000000000000000 > > > > [=A0=A0=A0 8.922111] x11: 0000000000000001 x10: 00000000000008e0 = x9 : ffff800012102a80 > > > > [=A0=A0=A0 8.922123] x8 : ffff000000d14b80 x7 : ffff0000fe7b12f0 = x6 : ffff0000fe7b1100 > > > > [=A0=A0=A0 8.922134] x5 : fffffc000000000f x4 : 0000000000000000 = x3 : 0000000000000001 > > > > [=A0=A0=A0 8.922145] x2 : 0000000000000001 x1 : 00000000ff190800 = x0 : ffff000000628c00 > > > > [=A0=A0=A0 8.922158] Call trace: > > > > [=A0=A0=A0 8.922163]=A0 dma_map_resource+0x68/0xc0 > > > > [=A0=A0=A0 8.922173]=A0 pl330_prep_slave_sg+0x58/0x220 > > > > [=A0=A0=A0 8.922181]=A0 rockchip_spi_prepare_dma+0xd8/0x2c0 [spi_= rockchip] > > > > [=A0=A0=A0 8.922208]=A0 rockchip_spi_transfer_one+0x294/0x3d8 [sp= i_rockchip] > > > [...] > > > > Note: This does not relate to the spi driver - when disabling thi= s device in > > > > the device tree it fails for any other (i2s, for instance) which = uses dma. > > > > Commenting out the failing check at [1], however, helps and the m= apping > > > > works again. > > > Do you know which address dma_map_resource() is trying to map (mayb= e > > > add some printk())? It's not supposed to map RAM, hence the warning= . > > > Random guess, the address is 0xff190800 (based on the x1 above but = the > > > regs might as well be mangled). > > 0xff190800 will cause this warning for sure. It has a memory map, but= it is > > not RAM so old version of pfn_valid() would return 0 and the new one > > returns 1. > > > > I tried to follow the recent changes for arm64 mm which could rel= ate to the > > > > check failing at [1] and reverting > > > > =A0 commit 16c9afc77660 ("arm64/mm: drop HAVE_ARCH_PFN_VALID") > > > > helps and makes it work again, but I'm 100% uncertain if that com= mit is > > > > really the culprit. > > > >=20 > > > > Note, that the firmware (legacy u-boot) injects memory configurat= ion in the > > > > device tree as follows: > > > >=20 > > > > /memreserve/=A0=A0=A0 0x00000000fcefc000 0x000000000000d000; > > > > / { > > > > .. > > > > =A0=A0=A0 compatible =3D "pine64,rock64\0rockchip,rk3328"; > > > > .. > > > > =A0=A0=A0 memory { > > > > =A0=A0=A0 =A0=A0=A0 reg =3D <0x00 0x200000 0x00 0xfee00000 0x00 = 0x00 0x00 0x00>; > > > > =A0=A0=A0 =A0=A0=A0 device_type =3D "memory"; > > > > =A0=A0=A0 }; > > > >=20 > > > > .. > > > > } > > > Either pfn_valid() gets confused in 5.14 or something is wrong with= the > > > DT. I have a suspicion it's the former since reverting the above co= mmit > > > makes it disappear. > > I think pfn_valid() actually behaves as expected but the caller is wr= ong > > because pfn_valid !=3D RAM (this applies btw to !arm64 as well). > >=20 > > /* Don't allow RAM to be mapped */ > > if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) > > return DMA_MAPPING_ERROR; > >=20 > > Alex, can you please try this patch: > >=20 > > diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c > > index 2b06a809d0b9..4715e9641a29 100644 > > --- a/kernel/dma/mapping.c > > +++ b/kernel/dma/mapping.c > > @@ -232,7 +232,7 @@ dma_addr_t dma_map_resource(struct device *dev, p= hys_addr_t phys_addr, > > return DMA_MAPPING_ERROR; > > /* Don't allow RAM to be mapped */ > > - if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) > > + if (WARN_ON_ONCE(!memblock_is_memory(phys_addr))) > > return DMA_MAPPING_ERROR; > > if (dma_map_direct(dev, ops)) >=20 > Nope, doesn't help: >=20 > [=A0=A0=A0 8.353879] dma_map_resource Failed to map address 0xff190800 > [=A0=A0=A0 8.353886] dma_map_resource pfn_valid(PHYS_PFN(0xff190800)): = 1 > [=A0=A0=A0 8.353892] dma_map_resource memblock_is_memory(0xff190800): 0 >=20 > If understand the comment for that check correct, that we _don't_ want = RAM > to be mapped - shoudn't that be: >=20 > + if (WARN_ON_ONCE(memblock_is_memory(phys_addr))) >=20 > ? Right, we don't want RAM to be mapped, the negation was wrong and it shou= ld be=20 if (WARN_ON_ONCE(memblock_is_memory(phys_addr))) =20 --=20 Sincerely yours, Mike.