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=-9.3 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 60989C4338F for ; Wed, 25 Aug 2021 10:00:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D36DF60EB0 for ; Wed, 25 Aug 2021 10:00:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D36DF60EB0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 18AB68D0001; Wed, 25 Aug 2021 06:00:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 114156B0071; Wed, 25 Aug 2021 06:00:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED0208D0001; Wed, 25 Aug 2021 06:00:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id CC02A6B006C for ; Wed, 25 Aug 2021 06:00:55 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 56C8C18031908 for ; Wed, 25 Aug 2021 10:00:55 +0000 (UTC) X-FDA: 78513159270.27.9767B61 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf21.hostedemail.com (Postfix) with ESMTP id 06FE1D017847 for ; Wed, 25 Aug 2021 10:00:54 +0000 (UTC) Received: by mail-wm1-f41.google.com with SMTP id c129-20020a1c35870000b02902e6b6135279so4218693wma.0 for ; Wed, 25 Aug 2021 03:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=t1Fxyis5VyGmJ28Q6mHHWuWqL/LfgK4tUw1UlmoXIy4=; b=N5KuOH68gGgamALSiXAw9kpRRby+Lo7oec2oseaOCeZD17MuGC7V/2taZQqmhnRrrw llWa01fwlfzXt2LvD2u6iM88oLcXN7KdEXYiWqFVBSdPwCXGg+npZDPL7LGN8uu0/BsL IKteQNg2ZoACgemT2X7DYthtTxs6ZM0RI3k8/M4JzNaeMklGbKqkRdio3CepznulmMU/ tKIaIAjwBaRY9E4toUvZzBWb6F4G7AcacllOwFah8pWqa9AKGVmGtG4Yi8Wm502v3CAo muY11dljK0DZ6LtlV+egTQJa623Vgv4GbK68v0lQEQQCJ7C4uhOlLvUViK95ECS0euI0 H4VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=t1Fxyis5VyGmJ28Q6mHHWuWqL/LfgK4tUw1UlmoXIy4=; b=NXyQeGCyAHrM6aeq4p4fJJVX/qmQoctXsQVX4bUcHqxt6/2bTjQnpa4ztIANHg+dx6 0TruGj1qNVvF7XjhFX8d1EFC1WmD5iMXsdnmNTrwDI5PSgr87X+v20h0OFXEf9mIE4VM ue7zNZlmrBz2EjA6OjheC5ikwn5wglUP6rC/OB8RFoMKzfDZJA4tKWJAqFIQgMIZlRFo PrzriQigjHE/klXvwZbTTNaZJiZeW+VxEDQgmgLMqewbEUoXjGqEZFcArRXCMsdtuegW e6k+Zzj+lFL4Ps+neuCW0RGa44+IVy+Gnz07pLnFVItohhjEDQ1OQ6s6YP48/R2Wblao s8Ig== X-Gm-Message-State: AOAM533it5DBbgaAjpMIg6ZhxLm9ywTozwkbUU+l78++uaoqpJ/fYiKv gVt55jmSi/5y7Iynu5NNGQ== X-Google-Smtp-Source: ABdhPJyK5pTAs+6faoY0ktiJjBdAA1GjMHLL4vMzg4mwYCD8skOjQ301m9pKh5f5wND2KvyHDP7ilg== X-Received: by 2002:a1c:1bce:: with SMTP id b197mr8108729wmb.43.1629885653723; Wed, 25 Aug 2021 03:00:53 -0700 (PDT) Received: from [192.168.200.23] (ip5b434083.dynamic.kabel-deutschland.de. [91.67.64.131]) by smtp.gmail.com with ESMTPSA id f20sm657674wmb.32.2021.08.25.03.00.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 03:00:53 -0700 (PDT) Subject: Re: [BUG 5.14] arm64/mm: dma memory mapping fails (in some cases) To: Mike Rapoport , Robin Murphy , Andrew Morton , Catalin Marinas Cc: Will Deacon , Anshuman Khandual , Linux Kernel Mailing List , linux-mm@kvack.org, Linux ARM References: <20210824173741.GC623@arm.com> From: Alex Bee Message-ID: <3bc0c465-475d-78e8-b742-ef093ebaf47c@gmail.com> Date: Wed, 25 Aug 2021 12:00:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=N5KuOH68; spf=pass (imf21.hostedemail.com: domain of knaerzche@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=knaerzche@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: m4t5q5hsdd49hjnkboaqc7esgsuncreq X-Rspamd-Queue-Id: 06FE1D017847 X-Rspamd-Server: rspam04 X-HE-Tag: 1629885654-873942 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: Am 25.08.21 um 06:39 schrieb Mike Rapoport: > On Tue, Aug 24, 2021 at 10:14:01PM +0200, Alex Bee wrote: >> Hi Mike, >> >> thanks for your reply >> >> 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, >>>> >>>> Thanks for the report. >>>> >>>> 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, sin= ce it >>>>> fails on Rockchip RK3328 when the pl330 dmac tries to map with: >>>>> >>>>> [=C2=A0=C2=A0=C2=A0 8.921909] ------------[ cut here ]------------ >>>>> [=C2=A0=C2=A0=C2=A0 8.921940] WARNING: CPU: 2 PID: 373 at kernel/dm= a/mapping.c:235 dma_map_resource+0x68/0xc0 >>>>> [=C2=A0=C2=A0=C2=A0 8.921973] Modules linked in: spi_rockchip(+) fu= se >>>>> [=C2=A0=C2=A0=C2=A0 8.921996] CPU: 2 PID: 373 Comm: systemd-udevd N= ot tainted 5.14.0-rc7 #1 >>>>> [=C2=A0=C2=A0=C2=A0 8.922004] Hardware name: Pine64 Rock64 (DT) >>>>> [=C2=A0=C2=A0=C2=A0 8.922011] pstate: 80000005 (Nzcv daif -PAN -UAO= -TCO BTYPE=3D--) >>>>> [=C2=A0=C2=A0=C2=A0 8.922018] pc : dma_map_resource+0x68/0xc0 >>>>> [=C2=A0=C2=A0=C2=A0 8.922026] lr : pl330_prep_slave_fifo+0x78/0xd0 >>>>> [=C2=A0=C2=A0=C2=A0 8.922040] sp : ffff800012102ae0 >>>>> [=C2=A0=C2=A0=C2=A0 8.922043] x29: ffff800012102ae0 x28: ffff000005= c94800 x27: 0000000000000000 >>>>> [=C2=A0=C2=A0=C2=A0 8.922056] x26: ffff000000566bd0 x25: 0000000000= 000001 x24: 0000000000000001 >>>>> [=C2=A0=C2=A0=C2=A0 8.922067] x23: 0000000000000002 x22: ffff000000= 628c00 x21: 0000000000000001 >>>>> [=C2=A0=C2=A0=C2=A0 8.922078] x20: ffff000000566bd0 x19: 0000000000= 000001 x18: 0000000000000000 >>>>> [=C2=A0=C2=A0=C2=A0 8.922089] x17: 0000000000000000 x16: 0000000000= 000000 x15: 0000000000000000 >>>>> [=C2=A0=C2=A0=C2=A0 8.922100] x14: 0000000000000277 x13: 0000000000= 000001 x12: 0000000000000000 >>>>> [=C2=A0=C2=A0=C2=A0 8.922111] x11: 0000000000000001 x10: 0000000000= 0008e0 x9 : ffff800012102a80 >>>>> [=C2=A0=C2=A0=C2=A0 8.922123] x8 : ffff000000d14b80 x7 : ffff0000fe= 7b12f0 x6 : ffff0000fe7b1100 >>>>> [=C2=A0=C2=A0=C2=A0 8.922134] x5 : fffffc000000000f x4 : 0000000000= 000000 x3 : 0000000000000001 >>>>> [=C2=A0=C2=A0=C2=A0 8.922145] x2 : 0000000000000001 x1 : 00000000ff= 190800 x0 : ffff000000628c00 >>>>> [=C2=A0=C2=A0=C2=A0 8.922158] Call trace: >>>>> [=C2=A0=C2=A0=C2=A0 8.922163]=C2=A0 dma_map_resource+0x68/0xc0 >>>>> [=C2=A0=C2=A0=C2=A0 8.922173]=C2=A0 pl330_prep_slave_sg+0x58/0x220 >>>>> [=C2=A0=C2=A0=C2=A0 8.922181]=C2=A0 rockchip_spi_prepare_dma+0xd8/0= x2c0 [spi_rockchip] >>>>> [=C2=A0=C2=A0=C2=A0 8.922208]=C2=A0 rockchip_spi_transfer_one+0x294= /0x3d8 [spi_rockchip] >>>> [...] >>>>> Note: This does not relate to the spi driver - when disabling this = device in >>>>> the device tree it fails for any other (i2s, for instance) which us= es dma. >>>>> Commenting out the failing check at [1], however, helps and the map= ping >>>>> works again. >>>> Do you know which address dma_map_resource() is trying to map (maybe >>>> 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 t= he >>>> 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 relat= e to the >>>>> check failing at [1] and reverting >>>>> =C2=A0 commit 16c9afc77660 ("arm64/mm: drop HAVE_ARCH_PFN_VALID") >>>>> helps and makes it work again, but I'm 100% uncertain if that commi= t is >>>>> really the culprit. >>>>> >>>>> Note, that the firmware (legacy u-boot) injects memory configuratio= n in the >>>>> device tree as follows: >>>>> >>>>> /memreserve/=C2=A0=C2=A0=C2=A0 0x00000000fcefc000 0x000000000000d00= 0; >>>>> / { >>>>> .. >>>>> =C2=A0=C2=A0=C2=A0 compatible =3D "pine64,rock64\0rockchip,rk3328= "; >>>>> .. >>>>> =C2=A0=C2=A0=C2=A0 memory { >>>>> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 reg =3D <0x00 0x200000 0x00= 0xfee00000 0x00 0x00 0x00 0x00>; >>>>> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 device_type =3D "memory"; >>>>> =C2=A0=C2=A0=C2=A0 }; >>>>> >>>>> .. >>>>> } >>>> 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 com= mit >>>> 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). >>> >>> /* Don't allow RAM to be mapped */ >>> if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) >>> return DMA_MAPPING_ERROR; >>> >>> Alex, can you please try this patch: >>> >>> 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)) >> Nope, doesn't help: >> >> [=C2=A0=C2=A0=C2=A0 8.353879] dma_map_resource Failed to map address 0= xff190800 >> [=C2=A0=C2=A0=C2=A0 8.353886] dma_map_resource pfn_valid(PHYS_PFN(0xff= 190800)): 1 >> [=C2=A0=C2=A0=C2=A0 8.353892] dma_map_resource memblock_is_memory(0xff= 190800): 0 >> >> If understand the comment for that check correct, that we _don't_ want= RAM >> to be mapped - shoudn't that be: >> >> + if (WARN_ON_ONCE(memblock_is_memory(phys_addr))) >> >> ? > Right, we don't want RAM to be mapped, the negation was wrong and it sh= ould > be > > if (WARN_ON_ONCE(memblock_is_memory(phys_addr))) > =20 OK, great: that helps with no other complaints - at least on this=20 (arm64) SoC. Since this affects all other archs, I doubt this will be in 5.14 - but=20 it would be great if there could be fix for that in 5.14 since at system=20 breaking bug. I'm not sure why it wasn't reported yet - is there any=20 chance that at least =C2=A0 commit 16c9afc77660 ("arm64/mm: drop HAVE_ARCH_PFN_VALID") can be reverted in 5.14? Alex