Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3508487pxb; Mon, 4 Apr 2022 19:15:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2HI791Xnvx0rMc2TIr8kd/5lztQTCF9eqGjxKHoea2e6AQ6UMFYY/PSq7rIcqyHLRj24k X-Received: by 2002:a63:1c22:0:b0:385:fcae:cb3f with SMTP id c34-20020a631c22000000b00385fcaecb3fmr981538pgc.102.1649124900025; Mon, 04 Apr 2022 19:15:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649124900; cv=none; d=google.com; s=arc-20160816; b=jh5JQ73nSB151W4aVzpxRdJYzIfHp3BQ3cPBrPG4iMoZat40Idyn+kOYn13a90rVmS fn9LsvpppHrn2qeV6zYxSi00myH8AxyzYcACylXwD6Vk1UCknsUQ8h59VNhrQdx5vy4A MANHAkfrchmBR90COHouyl7YYu3WefH/4b2TY3kN/DcmdrJQic1yNwOnbq84/pIWfJ8g kTB/cRfFAoWE9A/3liVK9VruiN131kXjiVt8d1ChdMVhwjJRCw7c+FVcHMKbMferms70 OEGjNQHKQTB6J07clTwzm7AwQXMdKIIPmSiquvSj6aWkOqf8RUBuWV9IiaNm34HoxmMc pi5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=GYOFxbnaPkCaL8rvz60xVT97yR/ZBBL4rwrJFtUiBYk=; b=atA05B63FxvA8/fDV0PHq1cOo31BoB+idjhWO/JTkrhGYFp6+UL5ouL+A6813OGI2c 1MWPYt0fjD6zACWoqcg+DZNkYkkr/LYBIcrljoMKIVu/3x8EZVRlK/SCTq6dym7rVjBj n2gov8luD2jyd+isq3TjES+s+Dm4EJO1gspBC0gBVSbQ6sr8HYOeoOcgKnBjPOCISluh PsuQxTc7f/rsT19Uxz3eU1TWRNqeSOGuM7ajjp9ytDiLKvY4Ifni9tjFWVq/Iqs7+zlC eYrm2N9HQAN16UiITQ6KDUyrRtZxq9HWYibz1wGrmHNUUPVK6fSBka+FaUxAGhCjwA5g x8+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=HCQKc+ec; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id j4-20020a056a00130400b004fa79753128si11653600pfu.62.2022.04.04.19.14.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 19:15:00 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=HCQKc+ec; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2B26F275CBB; Mon, 4 Apr 2022 17:37:31 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348103AbiDDP0g (ORCPT + 99 others); Mon, 4 Apr 2022 11:26:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239630AbiDDP0e (ORCPT ); Mon, 4 Apr 2022 11:26:34 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 816C3193EA for ; Mon, 4 Apr 2022 08:24:38 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id y38so18211732ybi.8 for ; Mon, 04 Apr 2022 08:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GYOFxbnaPkCaL8rvz60xVT97yR/ZBBL4rwrJFtUiBYk=; b=HCQKc+ecg4fdHb/+0UBrcWb9LzzGVNtRzOT37fNF/z9V/H5DyHu/DxS+IXrmYbSPrv leDKgRZBCQqQ2C1bKkyAYSPjo2SfdzzrSBUGbJPnZDYdVNsZsytDrjEOGyiHBTty9YwE G03EQ3IgVey/d8ZfUSa6MoL34bHO/IUM3izC2gZ6714JJjrKAit78+2omvGdyn3fadYC rUGBdtGs6YwOLEebecxbgoBWihHPsimiz/m8v4MNxhvAwjcO57lf6YWtgSS8O18HudDp 7795/xu8xMzDyaYUgpEwuhpwJVgFiXiI3HWNnc7crUPTHKkDsVBWp8i+abqteU/zhjwi s1lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GYOFxbnaPkCaL8rvz60xVT97yR/ZBBL4rwrJFtUiBYk=; b=rIADeSL/j6F/+YO9xbkvflmyQI90657vIXlcpTKV4p9c2HxZ37ZtqLFHM3sXgWCMHe r7ArzkLjBB7J4UMYqjzOBB0hWTdvOp6xfubfut4znW8QMoF/CDVC2DRrKQlODmnYjJFY y36hm5dB/atROV/ezQpEJIYAEstbF0EfVkn/o6GtiwyXjvprSSu8OGBSHZtjK4Rmo2Y+ ZeAdcFIaiLoS5i09Wgu47LP1Pig8/9o6hEjHR8/H1I33sJ/hR36m5by/iogwVmUJkeIA cr/a4Lhh04CYnnlROWQCQSZnLRecdf9bYOcsO9phBNeJ3PNFLK1s+I8F0UP5yXyuqw48 NTZA== X-Gm-Message-State: AOAM530gL7flxMfT2/bcl2dKFRTZl0mKIb6A/tpM/6AAf7e378HaeBAT y2gQOabGLVg3buUB9SiEGrLqRJjSCixBmtADEEFOaA== X-Received: by 2002:a25:e70e:0:b0:634:1a47:4ff2 with SMTP id e14-20020a25e70e000000b006341a474ff2mr275019ybh.89.1649085877745; Mon, 04 Apr 2022 08:24:37 -0700 (PDT) MIME-Version: 1.0 References: <20220403024928.4125-1-songmuchun@bytedance.com> <20220404091957.GA22790@willie-the-truck> In-Reply-To: From: Muchun Song Date: Mon, 4 Apr 2022 23:24:01 +0800 Message-ID: Subject: Re: [PATCH] arm64: mm: fix pmd_leaf() To: Aneesh Kumar K V Cc: Will Deacon , Catalin Marinas , Andrew Morton , Anshuman Khandual , steven.price@arm.com, lengxujun2007@126.com, Arnd Bergmann , LAK , LKML , Muchun Song , Xiongchun duan , Qian Cai Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 4, 2022 at 10:10 PM Aneesh Kumar K V wrote: > > On 4/4/22 5:10 PM, Muchun Song wrote: > > On Mon, Apr 4, 2022 at 5:20 PM Will Deacon wrote: > >> > >> On Sun, Apr 03, 2022 at 10:49:28AM +0800, Muchun Song wrote: > >>> The pmd_leaf() is used to test a leaf mapped PMD, however, it misses > >>> the PROT_NONE mapped PMD on arm64. Fix it. A real world issue [1] > >>> caused by this was reported by Qian Cai. > >>> > >>> Link: https://patchwork.kernel.org/comment/24798260/ [1] > >>> Fixes: 8aa82df3c123 ("arm64: mm: add p?d_leaf() definitions") > >>> Reported-by: Qian Cai > >>> Signed-off-by: Muchun Song > >>> --- > >>> arch/arm64/include/asm/pgtable.h | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > >>> index 94e147e5456c..09eaae46a19b 100644 > >>> --- a/arch/arm64/include/asm/pgtable.h > >>> +++ b/arch/arm64/include/asm/pgtable.h > >>> @@ -535,7 +535,7 @@ extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, > >>> PMD_TYPE_TABLE) > >>> #define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \ > >>> PMD_TYPE_SECT) > >>> -#define pmd_leaf(pmd) pmd_sect(pmd) > >>> +#define pmd_leaf(pmd) (pmd_present(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT)) > >>> #define pmd_bad(pmd) (!pmd_table(pmd)) > >>> > >>> #define pmd_leaf_size(pmd) (pmd_cont(pmd) ? CONT_PMD_SIZE : PMD_SIZE) > >> > >> A bunch of the users of pmd_leaf() already check pmd_present() -- is it > >> documented that we need to handle this check inside the macro? afaict x86 > >> doesn't do this either. > > > ppc64 also doesn't do a pmd_present check. > > >> > > > > arm64 is different from x86 here. pmd_leaf() could return true for > > the none pmd without pmd_present() check, the check of > > pmd_present() aims to exclude the pmd_none() case. However, > > it could work properly on x86 without pmd_present() or pmd_none(). > > So we don't see pmd_present() or pmd_none() check in pmd_leaf(). > > For this reason, I think this check is necessary. > > > > BTW, there are some users of pmd_leaf() (e.g. apply_to_pmd_range, > > walk_pmd_range, ptdump_pmd_entry) which do not check pmd_present() > > or pmd_none() before the call of pmd_leaf(). So it is also necessary > > to add the check. > > > > > I would expect pmd_leaf check to return true, if the said pmd page table > entry can point to a leaf page table entry which can also be a not > present page table entry? > All right. In order to exclude the pmd_none() case. How about the following code? #define pmd_leaf(pmd) (pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT)) Thanks.