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 45E28C021A4 for ; Mon, 24 Feb 2025 12:05:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE2B76B0095; Mon, 24 Feb 2025 07:05:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D92DC6B0096; Mon, 24 Feb 2025 07:05:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C341C6B0098; Mon, 24 Feb 2025 07:05:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A55EE6B0095 for ; Mon, 24 Feb 2025 07:05:02 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 807E81212FE for ; Mon, 24 Feb 2025 12:04:49 +0000 (UTC) X-FDA: 83154706698.02.28B7F6B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id C22F7C000D for ; Mon, 24 Feb 2025 12:04:47 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf28.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740398687; 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: in-reply-to:in-reply-to:references:references; bh=GLszEU23HGDAY7L9Om5/cPmM/j0KOfXexqqjf1oqMUM=; b=hrHxhVx//870ae8TbP7kEM2JD4cjVfsp83u5nUqtCQlHElocuOMp/6EZwPjvYuT+6tanMI +0QGbG4b8b6zUhwVCm8dFmPqIZGcQPvIyyliMA3F95D0CibtPm20OAUzu3OWMZJVo1H66K zGLRun/FP/3dtvfmAwAfu2/L9PKFTtE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740398687; a=rsa-sha256; cv=none; b=HWp54qrvlgA2Y63sxxZI26GmWPmqWCAnnJjGbVQ7MvV+QbG5RgE6wWmrtvc4mT5Yw9ZRG3 xhct4IG4hA9XCo1zhGZoubiXT0bOudV0Pav2A4+2xj+r9yTe1kShtfuI6ya4J+NBXQn2zv CYB1eGFKnPTdxyUm1U0xB9l1O274T7k= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf28.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1A49C5C6309; Mon, 24 Feb 2025 12:04:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 492DBC4CED6; Mon, 24 Feb 2025 12:04:44 +0000 (UTC) Date: Mon, 24 Feb 2025 12:04:42 +0000 From: Catalin Marinas To: Ryan Roberts Cc: Will Deacon , Pasha Tatashin , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , David Hildenbrand , "Matthew Wilcox (Oracle)" , Mark Rutland , Anshuman Khandual , Alexandre Ghiti , Kevin Brodsky , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 09/14] mm/vmalloc: Gracefully unmap huge ptes Message-ID: References: <20250217140809.1702789-1-ryan.roberts@arm.com> <20250217140809.1702789-10-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250217140809.1702789-10-ryan.roberts@arm.com> X-Rspam-User: X-Rspamd-Queue-Id: C22F7C000D X-Rspamd-Server: rspam07 X-Stat-Signature: c841jtu35ojc8sm7jko5woaiz3rg7bwg X-HE-Tag: 1740398687-393027 X-HE-Meta: U2FsdGVkX18GKSKOlldpQyaVK41+LwNbD5iL6wUoEK+eMOPRJ3AQJrWqJAd9W9xs6IW0qjuCA+OSWFHsC6quuoObc0WaLjyHNwvSCNgefq3rsYybNQDSYohi3nKZnRqD2zHDnAmB2cZmK0FJLRgkvT+y8lMCU8OJ14KI8B6yRLpifeNEt9qQ3wm1k9bS6rDAMVfW+1gY7LNGdsrEm+ivhzEI9jFYIMdmt+LRCY099iccLN9ADasWt+mMqEmsOdYQvTXlkxrV22eJLer+0UBLJZpKqFjR0H7azBgfSUNjRdNn79GEMfTGt9gkpLjbragQU4hHjrV0J/gx+vdYdaO/sKY999tMNTnyOqFZa8w7P062jcnZfc4XnDuMuX6eXj0YPpx0cMwqXNAmyfWn+xeDcJR87X/ReLPiPZ6FtOayOZoKlf+0ZSlOHIzd9ln+Lr3HjxAh0F1BWOd0I6LyuP1P155v0P6xJTie6aw4KDXRSjDBiHnXxoohYz/QwNFK1wNG4pidkz7AHWwlik2NQK6jFseGRwXRCzJF8mLI0L4dpDxbdRGuMc3CKPJCtX+Cd+7np4dxy7LNk5KU+q6vALpGHDq/NlkpsKqm9U2nkB6gTWJ0U2yrktCOscgnmaXCW2b2AoA/iJUIZLuegrEfh5QVwdPH0dQh//9tHfaBV5JxIiGDgEa6KQN+1AeOMecuX+Q5HWAf3eCPJ8OH11fiAqpbDlKso9OSbVTE87lI/n+FL8vH6a+tf/Zijh0+WVqMVn+zSFKZww6o/A+4+p7rhwi+a26LnO3wqViV1hHUfiewlN7x8N7CNkIntcfH49Ygu5tRK6lmody9a3v1o71N67NdCYOaCSyl35eJC7v4UsqYsoMSRfjr+DICavYiS+YvZfS6qWYfSnV4OueV7bRaBZYnWLN9IVkjBeih2xVM2MM58QYHXCQ0yn24QCjk7MNZXnnckGz9VF7dfjkAvkmaDDI rVpb+Fjd gR/8QkNa6i/t9k/OFS55ZuXis4scWbvj1mpm+684Tw1L4WcUpgUtZrdWm19KeBWYoXYD2QmRojAUBTJ+jH83NsHhzXASGWsgo/zOel81KA95vOEgys9UkjhNko4kKxh5o6vzhBarWtrXUSYh1Y973g6XGpgxO1WVqwarhvVpznKzn6NK0ve3mMurFYJ5fMPD+i29VGYXQzNbRcA5QAJO8x8Xq7Qz9UurLg3SYUgIl6tQfaHv/G+an8r7HYSkDszlW5R6ps5i+rd7TT77m9FkqmNRgPPHOxnjTuLxofwAGiyIhqwdoUFtOGKn9Tlc4CZd4t+0gwGtepjDSdHIj6Kr18/fgdPFO5EDGv2O60whTq5czwmPJVrpK8staEXMdU+b6g/izav2aizdtViVE+ZPZug86wQ== 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 Mon, Feb 17, 2025 at 02:08:01PM +0000, Ryan Roberts wrote: > Commit f7ee1f13d606 ("mm/vmalloc: enable mapping of huge pages at pte > level in vmap") added its support by reusing the set_huge_pte_at() API, > which is otherwise only used for user mappings. But when unmapping those > huge ptes, it continued to call ptep_get_and_clear(), which is a > layering violation. To date, the only arch to implement this support is > powerpc and it all happens to work ok for it. > > But arm64's implementation of ptep_get_and_clear() can not be safely > used to clear a previous set_huge_pte_at(). So let's introduce a new > arch opt-in function, arch_vmap_pte_range_unmap_size(), which can > provide the size of a (present) pte. Then we can call > huge_ptep_get_and_clear() to tear it down properly. > > Note that if vunmap_range() is called with a range that starts in the > middle of a huge pte-mapped page, we must unmap the entire huge page so > the behaviour is consistent with pmd and pud block mappings. In this > case emit a warning just like we do for pmd/pud mappings. > > Reviewed-by: Anshuman Khandual > Signed-off-by: Ryan Roberts Reviewed-by: Catalin Marinas