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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F18E8CDB47E for ; Wed, 18 Oct 2023 06:33:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZSioF43AunYFfHTyR9JAyGk1sfW28YATzDOjH7Sq/1U=; b=MR2vk+paMbJfTe 9xQ0BSp96MEDvgJCfHifnJaNNniSqyT3bdCy+eWy476HsNfVrmYGavJPgXk+NiN/pQdkXn48RfSg1 23+pm6b9K8jA8xaIvv08cPBlVfJvTDSiHYHNS46YNEjKphkhpukwfMNnvI9D2rTXCGCidUbgOwOTZ nAi7jaaaLV949/St/aTDC191wlLmPUNPHQaW2OFNeBRyebp1SYqeTUkUoEH8EJS/1RawWrJObitzi 1ff5koWonVzwvkuICTPAxP1eYjNxJlWySYCv9k6YdBG7hhi8CjKjp+Nawo01ySFYY1IqLOH93/h7d apw7idRlgUP7OLPdgmXw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qt07Q-00Dwq2-1e; Wed, 18 Oct 2023 06:33:24 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qt07O-00DwpZ-01 for linux-arm-kernel@lists.infradead.org; Wed, 18 Oct 2023 06:33:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697610798; h=from:from: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; bh=jZOwWocZpg3TtYCc3lshMN/KmY8LsIsl3wk4sUFMQX0=; b=I4Xh2/NczTkuzv8lmhuHaEkqfA1ryEazG8uHgtD+bwavbZamqnXJibU1nVnR9+8ecakuGk TRK/DQr7+NKZ/BvNe1AtQ+DcjDkc0NZYG0ALFnJ7LsuYfO+U1n1DIqdYtKpRb+dh8aKOQH y6L80itbqcXak/kd4dl5iyDu6utjAx0= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-652-oTkQLABaPZWQ_DKMUeMyPQ-1; Wed, 18 Oct 2023 02:33:16 -0400 X-MC-Unique: oTkQLABaPZWQ_DKMUeMyPQ-1 Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-27da5ad1dadso1899662a91.0 for ; Tue, 17 Oct 2023 23:33:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697610795; x=1698215595; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jZOwWocZpg3TtYCc3lshMN/KmY8LsIsl3wk4sUFMQX0=; b=nio1a8frlLxtPV024AlqxdQfT0ZuvRKfLwfT/2RhLZ1aF2Z+v6E+QaS+vOeShGbKDa lwnpZbxTTr3sS+vAbpCb5hbNXd8r4QTwomGajreoOxD6kmlY6XvY7KOO0y0eSrhiW/s/ nXkinzw2Y/AIiAXlXXOuO6z5/HdE9y3I3Hwob06lxptowF48U47UaIjsAPyQgLKujat/ +lGmar37mSK4pbt1QinTAiyKIbT1mDeFsSAMvuDRbqpGbxhEqlUCK/rHX/hz4Vs439cU mTlkI/7yoHnWWybwSFLKm9yS2sXMMt5xRI4YjlJAdNLHHom0oFqTnam5o2gJ1cHVlvUi XYYQ== X-Gm-Message-State: AOJu0YwuVRNfURcVK+qfxwDgI4D3GNq4kgKXi5+KjpB8DyyLTi+/gSXo yPUR2of8K8Ar5ANTDXSiuuXLMncwCpgb0LtpYgQucrkRFpRuMPCYVN7R/bmSskVzzNupQLUPRiA koO5gbowZaPL1M0Y+69eK7P6D4M+WkXxaeMU= X-Received: by 2002:a17:90a:8a10:b0:27d:5946:5e2c with SMTP id w16-20020a17090a8a1000b0027d59465e2cmr4206112pjn.12.1697610795655; Tue, 17 Oct 2023 23:33:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGWw4ftwVv6uW+EbPep50kB3uu7hdWqZ6N/43BWsuCBDIhlQAgYu8K5L/FuQYhclRZUt09c0g== X-Received: by 2002:a17:90a:8a10:b0:27d:5946:5e2c with SMTP id w16-20020a17090a8a1000b0027d59465e2cmr4206100pjn.12.1697610795272; Tue, 17 Oct 2023 23:33:15 -0700 (PDT) Received: from ?IPV6:2001:8003:e5b0:9f00:b890:3e54:96bb:2a15? ([2001:8003:e5b0:9f00:b890:3e54:96bb:2a15]) by smtp.gmail.com with ESMTPSA id 5-20020a17090a018500b0027782f611d1sm627549pjc.36.2023.10.17.23.33.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Oct 2023 23:33:14 -0700 (PDT) Message-ID: Date: Wed, 18 Oct 2023 16:33:09 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm64: mm: Validate CONFIG_PGTABLE_LEVELS conditionally To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com, shan.gavin@gmail.com References: <20231017005300.334140-1-gshan@redhat.com> From: Gavin Shan In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231017_233322_434914_DA465039 X-CRM114-Status: GOOD ( 31.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mark, On 10/17/23 21:05, Mark Rutland wrote: > On Tue, Oct 17, 2023 at 10:53:00AM +1000, Gavin Shan wrote: >> It's allowed for the fixmap virtual address space to span multiple >> PMD entries. Instead, the address space isn't allowed to span multiple >> PUD entries. However, PMD entries are folded to PUD and PGD entries >> in the following combination. In this particular case, the validation >> on NR_BM_PMD_TABLES should be avoided. >> >> CONFIG_ARM64_PAGE_SHIFT = 14 >> CONFIG_ARM64_VA_BITS_36 = y >> CONFIG_PGTABLE_LEVELS = 2 > > Is this something you found by inspection, or are you hitting a real issue on a > particular config? > > I built a kernel with: > > defconfig + CONFIG_ARM64_16K_PAGES=y + CONFIG_ARM64_VA_BITS_36=y > > ... which gives the CONFIG_* configuration you list above, and that works just > fine. > > For 2-level 16K pages we'd need to reserve more than 32M of fixmap slots for > the assertion to fire, and we only reserve ~6M of slots in total today, so I > can't see how this would be a problem unless you have 26M+ of local additions > to the fixmap? > > Regardless of that, I don't think it's right to elide the check entirely. > It's all about code inspection. When CONFIG_PGTABLE_LEVELS == 2, PGD/PUD/PMD are equivalent. The following two macros are interchangeable. The forthcoming static_assert() enforces that the fixmap virtual space can't span multiple PMD entries, meaning the space is limited to 32MB with above configuration. #define NR_BM_PMD_TABLES \ SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PUD_SHIFT) #define NR_BM_PMD_TABLES \ SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PMD_SHIFT) static_assert(NR_BM_PMD_TABLES == 1); However, multiple PTE tables are allowed. It means the fixmap virtual space can span multiple PMD entries, which is controversial to the above enforcement from the code level. Hopefully, I understood everything correctly. #define NR_BM_PTE_TABLES \ SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PMD_SHIFT) static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __page_aligned_bss; You're correct that the following edition is needed to trigger the assert. The point is to have the fixmap virtual space larger than 32MB. enum fixed_addresses { FIX_HOLE, : FIX_PTE, FIX_PMD, FIX_PUD, FIX_PGD, FIX_DUMMY = FIX_PGD + 2048, __end_of_fixed_addresses }; > The point of the check is to make sure that the fixmap VA range doesn't span > across multiple PMD/PUD/P4D/PGD entries, as the early_fixmap_init() and > fixmap_copy() code don't handle that in general. When using 2-level 16K pages, > we still want to ensure the fixmap is contained within a single PGD, and > checking that it falls within a single folded PMD will check that. > > See the message for commit: > > 414c109bdf496195 ("arm64: mm: always map fixmap at page granularity") > > ... and the bits that deleted from early_fixmap_init(). > > AFAICT this is fine as-is. > As I can see, multiple PMD entries can be handled well in early_fixmap_init(). However, multiple PMD entries aren't handled in fixmap_copy(), as you said. early_fixmap_init early_fixmap_init_pud early_fixmap_init_pmd // multiple PMD entries handled in the loop Thanks, Gavin >> >> Signed-off-by: Gavin Shan >> --- >> arch/arm64/mm/fixmap.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c >> index c0a3301203bd..5384e5c3aeaa 100644 >> --- a/arch/arm64/mm/fixmap.c >> +++ b/arch/arm64/mm/fixmap.c >> @@ -18,10 +18,11 @@ >> >> #define NR_BM_PTE_TABLES \ >> SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PMD_SHIFT) >> +#if CONFIG_PGTABLE_LEVELS > 2 >> #define NR_BM_PMD_TABLES \ >> SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PUD_SHIFT) >> - >> static_assert(NR_BM_PMD_TABLES == 1); >> +#endif >> >> #define __BM_TABLE_IDX(addr, shift) \ >> (((addr) >> (shift)) - (FIXADDR_TOT_START >> (shift))) >> -- >> 2.41.0 >> > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel