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 85C8DC02196 for ; Thu, 6 Feb 2025 13:05:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF5AE6B0085; Thu, 6 Feb 2025 08:05:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA56D6B0088; Thu, 6 Feb 2025 08:05:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBB326B0089; Thu, 6 Feb 2025 08:05:38 -0500 (EST) 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 BD6CD6B0085 for ; Thu, 6 Feb 2025 08:05:38 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CA4D8C12A2 for ; Thu, 6 Feb 2025 13:04:56 +0000 (UTC) X-FDA: 83089539834.16.95533AB Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 5083A120053 for ; Thu, 6 Feb 2025 13:04:54 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf29.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738847095; a=rsa-sha256; cv=none; b=kOmWZSpIChADWZ1Uu+XH0kW1zHzPmFZQkRtVtKBPOwUgv4a9vj+/CdP9IW2B5FgPtozVjd DYhCUL19I7HNeXJVsz2sXd4wBnvf+P1hj3f0jAKRifSQhHlS1n4XnpbPjtbe7UeqQy/pqv +ybMvAguKOEBjXyawrH6jqkd5DBajZU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf29.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738847095; 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; bh=kuimryCjZ2Ztqx7vxfPlkW5S79f/2oVyGI8EiyfQHMM=; b=f0Aq8bF7ey9SXqpTofec75t1MOP5mpy6TsDcVt0uYmBJ5As9XfXdsCo4BTrwAHsJrhzPNu CWwnTT2vRGB+8CLNjglBCjYtr73fO9cmCuVD+tSByrxArdMJ7A1tZG8fpKCwcEfcA/zL9X D3bUxA9sYxR4BSFYSclKMyPFNjYOpB8= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D6213FEC; Thu, 6 Feb 2025 05:05:07 -0800 (PST) Received: from [10.57.80.166] (unknown [10.57.80.166]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D4A733F5A1; Thu, 6 Feb 2025 05:04:41 -0800 (PST) Message-ID: Date: Thu, 6 Feb 2025 13:04:40 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/16] arm64: hugetlb: Fix flush_hugetlb_tlb_range() invalidation level Content-Language: en-GB To: Anshuman Khandual , Catalin Marinas , Will Deacon , Muchun Song , Pasha Tatashin , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mark Rutland , Ard Biesheuvel , Dev Jain , Alexandre Ghiti , Steve Capper , Kevin Brodsky Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20250205151003.88959-1-ryan.roberts@arm.com> <20250205151003.88959-4-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 5083A120053 X-Rspamd-Server: rspam10 X-Stat-Signature: 6dpacpjiwmihejx11rthcc88zi5huo96 X-HE-Tag: 1738847094-54620 X-HE-Meta: U2FsdGVkX1/siPmG1zCSRXlo4UvGazW1KvqTDRB0yxqDPO5XKAduPaQjeurp2A8NPQO3hIODiJrkdSd8H9uWLtJ309urjjWDGuw4FjSvd4/1H7OSC2T+UCppaEw9hGz4Mie7cPuMQedWU3H5UK64/0bntf2JwFor/tRGZcTaKcSlvLqFVDvtrv5317YgOJxf2Qz7VQ7Gv1km5LZjGlWoTpc/NYQjWssiYrdYOz07yXPLyfjr3cqh3HLotCwA40O/GUpmBqQKajH9st6Ao7j5+7GzDGBOEPus+iC597ZxjInGh4QwbK+oRIiG8mwmTPi3YdN9ZzBeRdvm3GFRkjvIXssEDYM43k7zRI5I09yxXNtu8tq0UPcOu1eKTNKyj9hQWH7n6eOEMxcuMY1MJK3Bit1O0isTlBzi6/A1IatgfhKxUo4SCpltWb9ryodzyD4hwTiTUOzMYhnFpSZ5jE2AVtUufcI7wC5rF8ZHJS+m4BWV7OyV5y3syvQ2ZbrKeLaitKDPRSK6/ZJBf2T1muJSCszyRZI6cbblu1c/G4Hy3mEUB1JY1vcHK6qvxfbP4bXTuG354b+I8bG3X06dpTXYR1XVZER95eyvpkE1DKWTuOgQAtMeazkJrRJ+7MWQS3IVutw0kGKZ0ooCR4bpSMRQqAv7Jsw0hhR77imx6KwbEfygiVpZJPLAG0iTrFAyUezN4ZRHULqzlGP4YOzap1QsICoYiocH73cRxCAsb09/1kbq9BJnNL8K2CF2OdisaSnZKakSkILI1ydleR/QdNUV0JtIaaFMM/aAFZKCwo9gdjTgoewMCKShjdpA1gN+oJqNCYVadICd/xxJFOJZh/nl+F8+az1CcCkAiKuxtBr3u5tobbrSzQ8J4yv4J7MNwP4kWLBbQ5h5+99OOkhAFfAByIwoLU6uafO1eBpd02hEjQ/mbX2FNdqYI4SobFKpJduQTJGqs435EEmuLDD0kmY 4EetbNEU j/1pOij15m+HQ28U45/0ps8zotjKeQl7eich49LhWcvYyxC42FJRwnGMunALFnMWUd9ebBiGqRlyLkslzK9SN6I3kVAJTmOvy1sC0Qt6cpQ0ZoM5K7cByUfTdDS1f4Ot8MK/TfmCPzRCg1Xf783Lgw9Zwk+8VEetg2g1UGyK3d4yqnlqJPGC5cdkyYRjLm4FekeZkK6gHREvIjxeVm6YSEEJq+OtBd9ZrfRFL6/FDuR225Oh+GhVjvCT9fhO8/IQLMlo9V+uD5MzUufHDeG6vrwe/tw== 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 06/02/2025 06:46, Anshuman Khandual wrote: > > > On 2/5/25 20:39, Ryan Roberts wrote: >> commit c910f2b65518 ("arm64/mm: Update tlb invalidation routines for >> FEAT_LPA2") changed the "invalidation level unknown" hint from 0 to >> TLBI_TTL_UNKNOWN (INT_MAX). But the fallback "unknown level" path in >> flush_hugetlb_tlb_range() was not updated. So as it stands, when trying >> to invalidate CONT_PMD_SIZE or CONT_PTE_SIZE hugetlb mappings, we will >> spuriously try to invalidate at level 0 on LPA2-enabled systems. >> >> Fix this so that the fallback passes TLBI_TTL_UNKNOWN, and while we are >> at it, explicitly use the correct stride and level for CONT_PMD_SIZE and >> CONT_PTE_SIZE, which should provide a minor optimization. >> >> Cc: >> Fixes: c910f2b65518 ("arm64/mm: Update tlb invalidation routines for FEAT_LPA2") >> Signed-off-by: Ryan Roberts >> --- >> arch/arm64/include/asm/hugetlb.h | 20 ++++++++++++++------ >> 1 file changed, 14 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h >> index 03db9cb21ace..8ab9542d2d22 100644 >> --- a/arch/arm64/include/asm/hugetlb.h >> +++ b/arch/arm64/include/asm/hugetlb.h >> @@ -76,12 +76,20 @@ static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma, >> { >> unsigned long stride = huge_page_size(hstate_vma(vma)); >> >> - if (stride == PMD_SIZE) >> - __flush_tlb_range(vma, start, end, stride, false, 2); >> - else if (stride == PUD_SIZE) >> - __flush_tlb_range(vma, start, end, stride, false, 1); >> - else >> - __flush_tlb_range(vma, start, end, PAGE_SIZE, false, 0); >> + switch (stride) { >> + case PUD_SIZE: >> + __flush_tlb_range(vma, start, end, PUD_SIZE, false, 1); >> + break; > > Just wondering - should not !__PAGETABLE_PMD_FOLDED and pud_sect_supported() > checks also be added here for this PUD_SIZE case ? Yeah I guess so. TBH, it's never been entirely clear to me what the benefit is? Is it just to remove (a tiny amount of) dead code when we know we don't support blocks at the level? Or is there something more fundamental going on that I've missed? We seem to be quite inconsistent with the use of pud_sect_supported() in hugetlbpage.c. Anyway, I'll add this in, I guess it's preferable to follow the established pattern. Thanks, Ryan > >> + case CONT_PMD_SIZE: >> + case PMD_SIZE: >> + __flush_tlb_range(vma, start, end, PMD_SIZE, false, 2); >> + break; >> + case CONT_PTE_SIZE: >> + __flush_tlb_range(vma, start, end, PAGE_SIZE, false, 3); >> + break; >> + default: >> + __flush_tlb_range(vma, start, end, PAGE_SIZE, false, TLBI_TTL_UNKNOWN); >> + } >> } >> >> #endif /* __ASM_HUGETLB_H */