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 7AFABC61CE7 for ; Wed, 11 Jun 2025 08:42:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11D856B008A; Wed, 11 Jun 2025 04:42:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CE336B008C; Wed, 11 Jun 2025 04:42:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00AD76B0096; Wed, 11 Jun 2025 04:42:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D90066B008A for ; Wed, 11 Jun 2025 04:42:25 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EFFD0100A08 for ; Wed, 11 Jun 2025 08:42:24 +0000 (UTC) X-FDA: 83542478208.30.69F56B6 Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by imf07.hostedemail.com (Postfix) with ESMTP id 499254000B for ; Wed, 11 Jun 2025 08:42:22 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=eKABDA52; spf=pass (imf07.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.12 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749631343; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8s5vFxR1V9KB58LvUJ18g2JnoUARTR5dGOv6Swwdcqg=; b=aq3rS1T/SMM2tadX0dCjSM66SXh0HAcL/SXRNuJ1x46tBIiNIjZwjdpyILvkaTHSVBjqLX dCT7MR5iwaS8Hw6RKXvJGw6SdKdoPzgmGvsA4DRLMU9umV+LnKRia+xcrdswEukUgWeabx Fq6+vNXEQ63Ngovz3nqGAycIR8y/dEw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=eKABDA52; spf=pass (imf07.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.12 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749631343; a=rsa-sha256; cv=none; b=qlwWj2VTVuQgwV/KOjMeEnXjvoKOx08mJJr14bvEYMhoLNDOdS4hfTijtfrq1pSIhh7MEi NrHx3jXeWYXEkE3niiak2MS+dpQtGQ37Qwo5OUJPXZL1u6netEGlRaUVRPQGpHABbT20S2 r1zmRG1vrjNikdDyKiFBNCYbU5ib4ig= Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20250611084220euoutp0231ddefa48825f3fb303065dac059942a~H8G8RxrFx2306823068euoutp02D for ; Wed, 11 Jun 2025 08:42:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250611084220euoutp0231ddefa48825f3fb303065dac059942a~H8G8RxrFx2306823068euoutp02D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1749631340; bh=8s5vFxR1V9KB58LvUJ18g2JnoUARTR5dGOv6Swwdcqg=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=eKABDA52uJCgR/L3d9qNuIbaW4Rixx/M1DCjpGb8hTMXsvy8voYkLO21aqUZRDobq J+x7a1RCq1JerI6pO/pYbEgKpIIZYHn6KZKaL8haxRIZjBaoKhN7xfCDeoNQLMHeTi 9P+MSw30GsrE7g6y2mqF6pPYqCixkkhR/9k7LjtY= Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20250611084219eucas1p1b1b445a9017d87f141561fa591847d7d~H8G78SWKX2272022720eucas1p1N; Wed, 11 Jun 2025 08:42:19 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250611084217eusmtip2665432f3fe30a8e815516687a8972357~H8G5lenbh2869928699eusmtip2v; Wed, 11 Jun 2025 08:42:17 +0000 (GMT) Message-ID: <4e53d612-534c-46b5-9746-a4a9814d41c3@samsung.com> Date: Wed, 11 Jun 2025 10:42:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: Remove PFN_MAP, PFN_SPECIAL, PFN_SG_CHAIN and PFN_SG_LAST To: David Hildenbrand , Alistair Popple Cc: linux-mm@kvack.org, akpm@linux-foundation.org, "linux-riscv@lists.infradead.org" , Christoph Hellwig , Jason Gunthorpe , gerald.schaefer@linux.ibm.com, dan.j.williams@intel.com, jgg@ziepe.ca, willy@infradead.org, linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev, jhubbard@nvidia.com, zhang.lyra@gmail.com, debug@rivosinc.com, bjorn@kernel.org, balbirs@nvidia.com, lorenzo.stoakes@oracle.com, John@groves.net Content-Language: en-US From: Marek Szyprowski In-Reply-To: <52b746ae-82cc-428e-8e88-a05a6b738cd0@redhat.com> Content-Transfer-Encoding: 8bit X-CMS-MailID: 20250611084219eucas1p1b1b445a9017d87f141561fa591847d7d X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250610161811eucas1p18de4ba7b320b6d6ff7da44786b350b6e X-EPHeader: CA X-CMS-RootMailID: 20250610161811eucas1p18de4ba7b320b6d6ff7da44786b350b6e References: <20250604032145.463934-1-apopple@nvidia.com> <957c0d9d-2c37-4d5f-a8b8-8bf90cd0aedb@samsung.com> <1daeaf4e-5477-40cb-bca0-e4cd5ad8a224@samsung.com> <52b746ae-82cc-428e-8e88-a05a6b738cd0@redhat.com> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 499254000B X-Stat-Signature: wyiwyg6pzgzjq9iq7g3pmer1ynfx31gj X-Rspam-User: X-HE-Tag: 1749631342-232797 X-HE-Meta: U2FsdGVkX18kQnG6WKgpBkOibA4xZZyQbuxs56lnkpId2XMlFQhYOPkWy3ntcQozjj6Y/nlPuJXPWxtDdTKEWUso+cr+y2P9Bmf5m9QIkKCoJ8xSKhIgn5ngXJkKbJoavSuV/6S8qpRjyUKMeFeTRM5SmFHj1NFcRm/L4MJqprfCbbxHRWg0SP11ca3NIR5QH9AqGfLW2XUX/w6aSZ8E6FEMH8pf5ju8+XkZgR0obARWxVBD3PrR9faPksgmkMs6Fg6Vusb+TVftbs0XCbp/ThA/TPoEqaopiAXYkQnwX0tFUUD0w+yCBoCM7rgfjrbqbVxacd3ysGK1nSbBIPCQPDrPwW3fOC2ngWZOFbcPMPXC755dKLu5OWG7mfvMrlXhPsWfkshWHkbNbJv/1KKRc64UCVzFIBwv2ZEvyF6WfSYmjGAzc/Jj9tUMSvF0U08d+oou+mDaVYv0vw/+x+sVqRrnqcjz77PsogXy/NZKZand7gv7QpovWbXuDw9cbTuSseWcRTYMMB4FTWqPCTC0yjhCx/dpduXNBQkbB9hLZ1BDgPywep3wmqUywpgHgk/07cV1oPjVrNm5W8/Gpk34hfa5UZM0J0MkOM4mKSRZSYROAy3lIMCMPa/vXkLhTN8Zj9e8Hwa95pl/rSdLf58gpIBIiJIava6hQ2L82JZ1L9Keau9ZFuN4cnDjVPkr+3ukl+nV/bJ753a2+wxpdebhDcaJlNvHQampgg1P/ApPQRA0mY5DSXw1Pzjpp9/qgGW0YpdOfVTrmL9CyGPnF0OnkGEB5RcqtsGPkBnI60DGrK3cIgNd+wfop91pKHDhxMIUz3yS0mvIHM9ljH4zeJIIdtb3/1ALpv/mK3s+Ou+HVkjZ7zU7NV9+rbTEBpmF53rmOHWwYk4ECgBmqj44MWaIUfF1gjVV+GxGL3GunwFgF5fl+3kvpbE0FTFty/i1KZO1dpSbiFdozKwh7bJqs+o fD+0X7u6 HKP4/zSl3bUlobw37KdFZpHKYeRYZtpW4OFj1BWI3DzHER/YelnW0xMQUky2JCTlD0R8ivXbU61+6KUWDrOjMN1jmWnFFm12u880zzHmgm5yk31pRrKEjEMMw/ynUU+7umFlgnBSxHjM4sTjsBgXqkWOw4McoUwZQYjq01Ad6awwaDTrqQ8CLBGvoC/gH1VbmLtC1gkIbGUSzTF0hzhHkjZy3zZH30p/0hq68gBhYrU07nQ80u9BfHU/iBbXlzZjVgPmOyWMjGhWijEo4R1zG/uBfVkl399AgD0+d 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 11.06.2025 10:23, David Hildenbrand wrote: > On 11.06.25 10:03, Marek Szyprowski wrote: >> On 11.06.2025 04:38, Alistair Popple wrote: >>> On Tue, Jun 10, 2025 at 06:18:09PM +0200, Marek Szyprowski wrote: >>>> On 04.06.2025 05:21, Alistair Popple wrote: >>>>> The PFN_MAP flag is no longer used for anything, so remove it. >>>>> The PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been >>>>> used so also remove them. The last user of PFN_SPECIAL was removed >>>>> by 653d7825c149 ("dcssblk: mark DAX broken, remove FS_DAX_LIMITED >>>>> support"). >>>>> >>>>> Signed-off-by: Alistair Popple >>>>> Acked-by: David Hildenbrand >>>>> Reviewed-by: Christoph Hellwig >>>>> Reviewed-by: Jason Gunthorpe >>>>> Cc: gerald.schaefer@linux.ibm.com >>>>> Cc: dan.j.williams@intel.com >>>>> Cc: jgg@ziepe.ca >>>>> Cc: willy@infradead.org >>>>> Cc: david@redhat.com >>>>> Cc: linux-kernel@vger.kernel.org >>>>> Cc: nvdimm@lists.linux.dev >>>>> Cc: jhubbard@nvidia.com >>>>> Cc: hch@lst.de >>>>> Cc: zhang.lyra@gmail.com >>>>> Cc: debug@rivosinc.com >>>>> Cc: bjorn@kernel.org >>>>> Cc: balbirs@nvidia.com >>>>> Cc: lorenzo.stoakes@oracle.com >>>>> Cc: John@Groves.net >>>>> >>>>> --- >>>>> >>>>> Splitting this off from the rest of my series[1] as a separate >>>>> clean-up >>>>> for consideration for the v6.16 merge window as suggested by >>>>> Christoph. >>>>> >>>>> [1] - >>>>> https://lore.kernel.org/linux-mm/cover.541c2702181b7461b84f1a6967a3f0e823023fcc.1748500293.git-series.apopple@nvidia.com/ >>>>> --- >>>>>     include/linux/pfn_t.h             | 31 >>>>> +++---------------------------- >>>>>     mm/memory.c                       |  2 -- >>>>>     tools/testing/nvdimm/test/iomap.c |  4 ---- >>>>>     3 files changed, 3 insertions(+), 34 deletions(-) >>>> This patch landed in today's linux-next as commit 28be5676b4a3 ("mm: >>>> remove PFN_MAP, PFN_SPECIAL, PFN_SG_CHAIN and PFN_SG_LAST"). In my >>>> tests >>>> I've noticed that it breaks operation of all RISC-V 64bit boards on my >>>> test farm (VisionFive2, BananaPiF3 as well as QEMU's Virt machine). >>>> I've >>>> isolated the changes responsible for this issue, see the inline >>>> comments >>>> in the patch below. Here is an example of the issues observed in the >>>> logs from those machines: >>> Thanks for the report. I'm really confused by this because this >>> change should >>> just be removal of dead code - nothing sets any of the removed PFN_* >>> flags >>> AFAICT. >>> >>> I don't have access to any RISC-V hardwdare but you say this >>> reproduces under >>> qemu - what do you run on the system to cause the error? Is it just >>> a simple >>> boot and load a module or are you running selftests or something else? >> >> It fails a simple boot test. Here is a detailed instruction how to >> reproduce this issue with the random Debian rootfs image found on the >> internet (tested on Ubuntu 22.04, with next-20250610 >> kernel source): > > riscv is one of the archs where pte_mkdevmap() will *not* set the pte > as special. (I > raised this recently in the original series, it's all a big mess) > > So, before this change here, pfn_t_devmap() would have returned > "false" if only > PFN_DEV was set, now it would return "true" if only PFN_DEV is set. > > Consequently, in insert_pfn() we would have done a pte_mkspecial(), > now we do a > pte_mkdevmap() -- again, which does not imply "special" on riscv. > > riscv selects CONFIG_ARCH_HAS_PTE_SPECIAL, so if !pte_special(), it's > considered as > normal. > > Would the following fix your issue? > > > diff --git a/mm/memory.c b/mm/memory.c > index 8eba595056fe3..0e972c3493692 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -589,6 +589,10 @@ struct page *vm_normal_page(struct vm_area_struct > *vma, unsigned long addr, >  { >         unsigned long pfn = pte_pfn(pte); > > +       /* TODO: remove this crap and set pte_special() instead. */ > +       if (pte_devmap(pte)) > +               return NULL; > + >         if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) { >                 if (likely(!pte_special(pte))) >                         goto check_pfn; > @@ -598,16 +602,6 @@ struct page *vm_normal_page(struct vm_area_struct > *vma, unsigned long addr, >                         return NULL; >                 if (is_zero_pfn(pfn)) >                         return NULL; > -               if (pte_devmap(pte)) > -               /* > -                * NOTE: New users of ZONE_DEVICE will not set > pte_devmap() > -                * and will have refcounts incremented on their struct > pages > -                * when they are inserted into PTEs, thus they are > safe to > -                * return here. Legacy ZONE_DEVICE pages that set > pte_devmap() > -                * do not have refcounts. Example of legacy > ZONE_DEVICE is > -                * MEMORY_DEVICE_FS_DAX type in pmem or virtio_fs > drivers. > -                */ > -                       return NULL; > >                 print_bad_pte(vma, addr, pte, NULL); >                 return NULL; > > > But, I would have thought the later patches in Alistairs series would > sort that out > (where we remove pte_devmap() ... ) > The above change fixes the issues observed on RISCV boards. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland