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 43FF4C7EE30 for ; Wed, 25 Jun 2025 11:09:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C287B6B00A1; Wed, 25 Jun 2025 07:09:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C00056B00AC; Wed, 25 Jun 2025 07:09:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3D496B00AF; Wed, 25 Jun 2025 07:09:23 -0400 (EDT) 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 A22586B00A1 for ; Wed, 25 Jun 2025 07:09:23 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 44B90B6D43 for ; Wed, 25 Jun 2025 11:09:23 +0000 (UTC) X-FDA: 83593651806.13.2D787A2 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id DDBC4120009 for ; Wed, 25 Jun 2025 11:09:20 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; 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; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750849761; 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=Gj51cTkdtVCvEEjOlkEXFEweDA+pGJwJ9Da0qmJyqZA=; b=e73tJJxfzV0586PDRXZxdLIeIYgrMMMDG/MeiL8U5dZJSihonRBKmF5SDZKh4PkA/B7Kto AIGW5QPgWgSfH46H6gUbu65vRLszwdm2Z44/hCqIBclHkOyVZuclYjjeo8ToTjDHa+x+Ve XHEYCo5PF2JLkx6qeBq8RE2g4XTpWLA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; 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; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750849761; a=rsa-sha256; cv=none; b=n9a95FXb1HdWO3aYHkiZ+rdiljnHTasexqAV69/hZ/RwKhAp+w1Mlepe3C16FN2UFU6Fpj HC8f17YCPdvcM4kZCctPXD1LT1CHXR6+wbHuJgB2dyLSDPtHkn4ytPEttvp1mjSjjQMLmO lJAwGOKosGqF+zVn/Dc5CPLDoXL4WtU= 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 23FB8106F; Wed, 25 Jun 2025 04:09:01 -0700 (PDT) Received: from [10.57.84.221] (unknown [10.57.84.221]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 043DD3F58B; Wed, 25 Jun 2025 04:09:09 -0700 (PDT) Message-ID: <400b6d4e-bf10-4b89-bcbe-2375b1972220@arm.com> Date: Wed, 25 Jun 2025 12:08:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] arm64: pageattr: Enable huge-vmalloc permission change Content-Language: en-GB To: Dev Jain , akpm@linux-foundation.org, david@redhat.com, catalin.marinas@arm.com, will@kernel.org Cc: lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, steven.price@arm.com, gshan@redhat.com, linux-arm-kernel@lists.infradead.org, yang@os.amperecomputing.com, anshuman.khandual@arm.com References: <20250613134352.65994-1-dev.jain@arm.com> <20250613134352.65994-3-dev.jain@arm.com> From: Ryan Roberts In-Reply-To: <20250613134352.65994-3-dev.jain@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: DDBC4120009 X-Stat-Signature: crgnzumgtogpj7x6eteqhwunasuuxcg1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1750849760-200880 X-HE-Meta: U2FsdGVkX18uxElIclzoS2R4FIFwLY1jK0LoKTnjB9ae4LMCGVGULVkPppaTDJzP0RL44iZnLIyyGg934rX6iZBJ3I/ECw0ehMOeIe01TU/PsJQpTV7QtxiQZrBpbf4UzlFgJWdRFuj2uI7B0tkjf4oHZgXCcZxd8m+As4Uj/oXAYFYrKNNZ//lscj7M+rJtkqVjtICwr/2N6dFAyxYF8kl0RlS/rkiicYnfHHgNEXFn9UTD4z4N+Cm9/+5gZf08mt/DMIlgzkuWjPFAPPdmeChoN52Hz0c/JKAN7GMg8dfIsawowGY1P7YJhIrcMFVR9YRHd9eGskIm8AIzN3ym6NirOS0+PFIWKrwpkrcxzdBWm4lELkTA6ztorT0/ZzN/TzGvXPTJMTWGpy9p6J75UxNGfplwWxxRFsOom49vbzUEdUICiNCi63rAQxG+pT4p72sGeMcPjHf8KaNhlnIMr5aEzqP1okRcZPT6BoTDkL6Lcex7rPM6ESQd4ykx92sjc7lEGVPHrQuGqMTpd84quYjdiI7ehMDTpe+TF5oxCbTfDOldOxwbjcWgkFG+3I0TrJYbhlsuK7YXPpWVgBPn5WDGczczkNfZqGb8hh6AZemPVcqv+ePabPzlNA/RGXsXa0vmXEGrP9zAVO2tbEnBpkKohdB0W4Gz2aE1Yk+xrbOk/mDqXM15zxiNhq6VPjCRU8QGjQsx+EEnb8xSI0zfQfiD0jXaaZ5ryBYEqcBW1gwNaiyTyTrFO2T00ex7pEiMHHr8QkRqNxH2htF6zaUZDZz/x73mqyG66eZOyaE8dLyTE33x0M+yE7aOAuRZW4CU2AQcpQ72U7kHcccXLZWdAz2Vqw5p0Glj8ihZfKZUDm90cg/ksMpv/CmQ4zLKm+xYbrvH63dVQ2OUUmwuApG4Hlw+JnL8AXDTJkipu6BXwjnPJmR8g9eGpvwW8Qy6tQyGnQY57ElNwlIFBd4xXCc 4GBCl3KP 21Q3EvVW5gjFuRa7Xuep7uYNKg9RY1uRMMtjN3EDXoqefWRi28+qDK1/AuYAVHdOtZsg3kMetyc3K5bJ9t5ZQaO+7/zoUP5Q6o9tinDVh4t5wX4x8WXF4zPGxr9ceHDExcHvDUXi76he09lSCveQXLG1/kF17tm6u63GQ/MWfyY3aFobgiVAueT5Bu1ok5mqcNG0SyKs6sE7rFy4= 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 13/06/2025 14:43, Dev Jain wrote: > Commit fcf8dda8cc48 ("arm64: pageattr: Explicitly bail out when changing > permissions for vmalloc_huge mappings") disallowed changing permissions > for vmalloc-huge mappings. The motivation of this was to enforce an API > requirement and explicitly tell the caller that it is unsafe to change > permissions for block mappings since splitting may be required, which > cannot be handled safely on an arm64 system in absence of BBML2. > > This patch effectively partially reverts this commit, since patch 1 > will now enable permission changes on kernel block mappings, thus, > through change_memory_common(), enable permission changes for vmalloc-huge > mappings. Any caller "misusing" the API, in the sense, calling it for > a partial block mapping, will receive an error code of -EINVAL via > the pagewalk callbacks, thus reverting to the behaviour of the API > itself returning -EINVAL, through apply_to_page_range returning -EINVAL > in case of block mappings, the difference now being, the -EINVAL is > restricted to playing permission games on partial block mappings > courtesy of patch 1. > > Signed-off-by: Dev Jain > --- > arch/arm64/mm/pageattr.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c > index cfc5279f27a2..66676f7f432a 100644 > --- a/arch/arm64/mm/pageattr.c > +++ b/arch/arm64/mm/pageattr.c > @@ -195,8 +195,6 @@ static int change_memory_common(unsigned long addr, int numpages, > * we are operating on does not result in such splitting. > * > * Let's restrict ourselves to mappings created by vmalloc (or vmap). > - * Disallow VM_ALLOW_HUGE_VMAP mappings to guarantee that only page > - * mappings are updated and splitting is never needed. > * > * So check whether the [addr, addr + size) interval is entirely > * covered by precisely one VM area that has the VM_ALLOC flag set. > @@ -204,7 +202,7 @@ static int change_memory_common(unsigned long addr, int numpages, > area = find_vm_area((void *)addr); > if (!area || > end > (unsigned long)kasan_reset_tag(area->addr) + area->size || > - ((area->flags & (VM_ALLOC | VM_ALLOW_HUGE_VMAP)) != VM_ALLOC)) > + !(area->flags & VM_ALLOC)) > return -EINVAL; > > if (!numpages) I'd be inclined to leave this restriction in place for now. It is not useful until we have context of the full vmalloc-huge-by-default series, I don't think?