Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp2983588rdb; Fri, 22 Sep 2023 14:15:45 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHfqO5wgmoTQnqimJiDb2XtwB/4ZC6DGfAAe1INHAAcCuZePf4y4XKlVBucL3Nd9798lJo3 X-Received: by 2002:a17:902:e80e:b0:1c5:daf1:271e with SMTP id u14-20020a170902e80e00b001c5daf1271emr682016plg.28.1695417345325; Fri, 22 Sep 2023 14:15:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695417345; cv=none; d=google.com; s=arc-20160816; b=NpFPVMlZqcC2NU99y+0JPAnh99RSuxanvchwp5YWFKMERT2mK5gW1It1pVrRagIu/m vvsYZb6a5XmjUWFBKEmk4fPclpNvMCSuxQ+zgxNe0RZ3f7sxYRsK2IMhDMP7sBgDkXnH caxNH6XO86koZFTLKv2/9qEpgSpgPEKkNLqenvqks2v2hyqLJeFtX0CUKa3ECKrPiDne GPUAszV0LSO5X588/cQii9/l3YgJzQyoF/GZ4nJhcsQVONQBhc/OW3x0qdIUgeFVUUFy Ys/3fH2vu259TqQAZF/lnrmnzMf4q7+39ALlGJrcLzk9BJ1GzGpSIdAxGyJIl32ZXLat JtcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=YZMr1kN15ref1wUYr4E6kS3JTBkLGuuuWxsn4v7voMQ=; fh=hIcedKh4mzVmdSOcooq/ubMXZLUUAY9wBQ5RKWOgKg4=; b=wmiWGgs66pWt/HFGJ5D5I4QpKC3L89/h4FD0HKMjeHFnVtKreB7FJwBDq9xQ33nQj4 YwgrrLCaF6RO0m9ktrfvdCGEM7r8HuJ1J088OjnbljWpL1AYYan5yrps+INiz60kOphO HaUxRs8JKIW1U0znep0npE3faOCNNzCuDVIucQaILKmSlCGP1Dk1mQiTpA7xk5YyTZzq u5HOisFTSy7ZCF3JHBAmY6evAHxpA0q8aEeEosvgtA1QFhwhH6Br1rZVkC/523id1wGW oOu/KaKOzbQvF8sBmE5FAHeR/hrBt56PI35bHoUIIrJyTsKY16Su7Il3nbxDGfb0VdNu cnag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=OX56MkhY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id s11-20020a170903200b00b001bbbd9cd44bsi4167362pla.79.2023.09.22.14.15.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 14:15:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=OX56MkhY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 995808068881; Fri, 22 Sep 2023 10:09:58 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229971AbjIVRJ4 (ORCPT + 99 others); Fri, 22 Sep 2023 13:09:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229572AbjIVRJz (ORCPT ); Fri, 22 Sep 2023 13:09:55 -0400 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60B5B192 for ; Fri, 22 Sep 2023 10:09:48 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-99bdeae1d0aso294500866b.1 for ; Fri, 22 Sep 2023 10:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695402587; x=1696007387; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YZMr1kN15ref1wUYr4E6kS3JTBkLGuuuWxsn4v7voMQ=; b=OX56MkhYo96iSH/9jTtGmowa0IWzk2k5Qm+D9h7oPJOjJ/+Zsko+SIn9DNNw33kZ0F a1NC0h7yfuFZekYPR50aSDIkD/lyzGW/pcJUXLxVvGnqplA4AxTwoqqe3X31dVef8StM KDrBAEzwp5I0HqGKrSRHFTrrhWlf+5wls8mZbwjU5eL8dwNEsaFxZPt/KoDmdFuIDvDv Tx4RYM0g/D0MzcS75yveTi1qJZgbvpkfBEEYorNb4I9V0T260/jrCtnzyVlHRd4yHkxz HsjgZgFPTKZB0LrQb3QDGf6/RebAJi30u5vWLYIsZtjfFNLmia/XD09ljRrFSAI8tIZC 4/3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695402587; x=1696007387; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YZMr1kN15ref1wUYr4E6kS3JTBkLGuuuWxsn4v7voMQ=; b=UkUNrkfd5UQOPokM11O37ZLMVSoWaWIzWXkQCOZjdL9Z91HHxq+HqIpr2LAtNXvw2S LvyS7BG5b7L2D6F7OMdHwt5fQ9HqXYfxk1FgjheKszNOSZriism6NUMoLJcYvq9NJ7rZ tShasc4DDSPqoZJPkhe5PZghJ5/oSovek0RFrTO6Em87j15mAf4lja1n0lqy3YBsnbV+ atPFwpGxFpoLvSPozFNJ9KpTg7Qjxz64HXjSv76CdN9I6AWujboaQEljy+Rntkq6w2ZZ bYUpNaRPzt6dLpuYr4w8h2SW54xh/V8LErF7tRUuSInwsfn22PRPXEubxMJziiVCvwjT XXBQ== X-Gm-Message-State: AOJu0YwWNKVRLkYx+ksS/ZACK3aBL5JJ2hp1WpGsx9DsaVABXS5z+h0i Q4Sz0Ib29byHjJFt02rFBk+3/k4bY62Lo8023ImmbQ== X-Received: by 2002:a17:907:985b:b0:9a2:1ce5:1243 with SMTP id jj27-20020a170907985b00b009a21ce51243mr7710566ejc.60.1695402586369; Fri, 22 Sep 2023 10:09:46 -0700 (PDT) MIME-Version: 1.0 References: <20230922115804.2043771-1-ryan.roberts@arm.com> <20230922115804.2043771-3-ryan.roberts@arm.com> <20230922161404.GA23332@willie-the-truck> <32052cb7-91f1-461d-a226-2cd2fcf34ad2@arm.com> In-Reply-To: <32052cb7-91f1-461d-a226-2cd2fcf34ad2@arm.com> From: Axel Rasmussen Date: Fri, 22 Sep 2023 10:09:08 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries To: Ryan Roberts Cc: Will Deacon , Catalin Marinas , "James E.J. Bottomley" , Helge Deller , Nicholas Piggin , Christophe Leroy , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Gerald Schaefer , "David S. Miller" , Arnd Bergmann , Mike Kravetz , Muchun Song , SeongJae Park , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Anshuman Khandual , Peter Xu , Qi Zheng , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Fri, 22 Sep 2023 10:09:59 -0700 (PDT) Looks correct to me - thanks for the fix! Reviewed-by: Axel Rasmussen On Fri, Sep 22, 2023 at 9:41=E2=80=AFAM Ryan Roberts = wrote: > > On 22/09/2023 17:14, Will Deacon wrote: > > On Fri, Sep 22, 2023 at 12:58:04PM +0100, Ryan Roberts wrote: > >> When called with a swap entry that does not embed a PFN (e.g. > >> PTE_MARKER_POISONED or PTE_MARKER_UFFD_WP), the previous implementatio= n > >> of set_huge_pte_at() would either cause a BUG() to fire (if > >> CONFIG_DEBUG_VM is enabled) or cause a dereference of an invalid addre= ss > >> and subsequent panic. > >> > >> arm64's huge pte implementation supports multiple huge page sizes, som= e > >> of which are implemented in the page table with multiple contiguous > >> entries. So set_huge_pte_at() needs to work out how big the logical pt= e > >> is, so that it can also work out how many physical ptes (or pmds) need > >> to be written. It previously did this by grabbing the folio out of the > >> pte and querying its size. > >> > >> However, there are cases when the pte being set is actually a swap > >> entry. But this also used to work fine, because for huge ptes, we only > >> ever saw migration entries and hwpoison entries. And both of these typ= es > >> of swap entries have a PFN embedded, so the code would grab that and > >> everything still worked out. > >> > >> But over time, more calls to set_huge_pte_at() have been added that se= t > >> swap entry types that do not embed a PFN. And this causes the code to = go > >> bang. The triggering case is for the uffd poison test, commit > >> 99aa77215ad0 ("selftests/mm: add uffd unit test for UFFDIO_POISON"), > >> which causes a PTE_MARKER_POISONED swap entry to be set, coutesey of > >> commit 8a13897fb0da ("mm: userfaultfd: support UFFDIO_POISON for > >> hugetlbfs") - added in v6.5-rc7. Although review shows that there are > >> other call sites that set PTE_MARKER_UFFD_WP (which also has no PFN), > >> these don't trigger on arm64 because arm64 doesn't support UFFD WP. > >> > >> Arguably, the root cause is really due to commit 18f3962953e4 ("mm: > >> hugetlb: kill set_huge_swap_pte_at()"), which aimed to simplify the > >> interface to the core code by removing set_huge_swap_pte_at() (which > >> took a page size parameter) and replacing it with calls to > >> set_huge_pte_at() where the size was inferred from the folio, as > >> descibed above. While that commit didn't break anything at the time, i= t > >> did break the interface because it couldn't handle swap entries withou= t > >> PFNs. And since then new callers have come along which rely on this > >> working. But given the brokeness is only observable after commit > >> 8a13897fb0da ("mm: userfaultfd: support UFFDIO_POISON for hugetlbfs"), > >> that one gets the Fixes tag. > >> > >> Now that we have modified the set_huge_pte_at() interface to pass the > >> huge page size in the previous patch, we can trivially fix this issue. > >> > >> Signed-off-by: Ryan Roberts > >> Fixes: 8a13897fb0da ("mm: userfaultfd: support UFFDIO_POISON for huget= lbfs") > >> Cc: # 6.5+ > >> --- > >> arch/arm64/mm/hugetlbpage.c | 17 +++-------------- > >> 1 file changed, 3 insertions(+), 14 deletions(-) > >> > >> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c > >> index a7f8c8db3425..13fd592228b1 100644 > >> --- a/arch/arm64/mm/hugetlbpage.c > >> +++ b/arch/arm64/mm/hugetlbpage.c > >> @@ -241,13 +241,6 @@ static void clear_flush(struct mm_struct *mm, > >> flush_tlb_range(&vma, saddr, addr); > >> } > >> > >> -static inline struct folio *hugetlb_swap_entry_to_folio(swp_entry_t e= ntry) > >> -{ > >> - VM_BUG_ON(!is_migration_entry(entry) && !is_hwpoison_entry(entry)= ); > >> - > >> - return page_folio(pfn_to_page(swp_offset_pfn(entry))); > >> -} > >> - > >> void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, > >> pte_t *ptep, pte_t pte, unsigned long sz) > >> { > >> @@ -257,13 +250,10 @@ void set_huge_pte_at(struct mm_struct *mm, unsig= ned long addr, > >> unsigned long pfn, dpfn; > >> pgprot_t hugeprot; > >> > >> - if (!pte_present(pte)) { > >> - struct folio *folio; > >> - > >> - folio =3D hugetlb_swap_entry_to_folio(pte_to_swp_entry(pt= e)); > >> - ncontig =3D num_contig_ptes(folio_size(folio), &pgsize); > >> + ncontig =3D num_contig_ptes(sz, &pgsize); > >> > >> - for (i =3D 0; i < ncontig; i++, ptep++) > >> + if (!pte_present(pte)) { > >> + for (i =3D 0; i < ncontig; i++, ptep++, addr +=3D pgsize) > >> set_pte_at(mm, addr, ptep, pte); > > > > Our set_pte_at() doesn't use 'addr' for anything and the old code didn'= t > > even bother to increment it here! I'm fine adding that, but it feels > > unrelated to the issue which this patch is actually fixing. > > True. I agree its not strictly necessary and will presumably be optimized= out. > But I'm not sure that having knowledge that the implementation doesn't us= e it is > a good reason not to call the interface correctly. I'll leave it as I've = done it > if that's ok. > > > > > Either way: > > > > Acked-by: Will Deacon > > Thanks! > > > > > Will >