From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7955352031 for ; Sun, 23 Aug 2026 16:52:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787503976; cv=none; b=uiXO2bWC0ESp0u4NuYf0HhTQJ+sMe73r4pN9c+jRtCjGNAv85T7nOUehiMXZcWWOjaxwsEEKwYmwMPMhnbsgDy0a/uVDhX6p2zkInrc4ue7IbwtsEfAl/tXpX6ia9kwaEfiLlPodv9uFjTo2vy6d/+T9ZZ2mR/xJL5T7CBGIjsI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787503976; c=relaxed/simple; bh=hWjQifge1RAK6z478R1PFnRWX2lnMwsgDiVDTSmBsn8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sygYuqxjuGfJ/zFFug52/j8k/jZEN/b69+ZtvhFm/e7njUYBMJBXSkzrZwthLgyeJQ4+CyPcbiQvAUqX7Oz4dZKmqyk6JsndPVchaMAu0I7mF6oFI7z8lweAobykNPFhwvGMooU23v8FVQD1OJzm+sXktxF6V8Y5RsiUZFQSHF0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GSR/krCB; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GSR/krCB" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-498028b3d5eso27835395e9.1 for ; Sun, 23 Aug 2026 09:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1787503972; x=1788108772; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=QjRcKycCgEIdRjuuH2tPItX4wlK7ZDllY3I75Ar7NjE=; b=GSR/krCBETjHDRHfIT+yJupj3qM6I2DiEfRPvo0ckTQ7BwoR7fYMdY/yytfRR8kufQ fVf2aFwMqflvHWsUNWfWyrzeF/7LICRSVmzT7H0xiA+zI9f02Eb1Wco3bdatGBSpZqIL gfQugnMPnF6zGU8SrmrBJM8DgbVUdDxu1jNaaIBm+j6/nFciAPFAVSQcLSyvPdtBfMob 8U2YUVf8Ib6S28kOlvl3YDp+P+msDCi6ZngCAJ1sNC8KQf811M8TJluLgzeZCwhnFPyz qEG6GyFh30l7hiUaYSQlwTph8cagFfArmxfYNA16Q9qgurPz6bb9UReRJNCx/4hiiddF fhXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787503972; x=1788108772; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=QjRcKycCgEIdRjuuH2tPItX4wlK7ZDllY3I75Ar7NjE=; b=ESGWYwCwyaINNOeeWwxEIsFmlcstLBScOnH8y8C/Pe9eu8g+ZOVj7rPlz56+AG6GUc r0wZM4ln/zE27qREmjy0muGPULnrtjjRQ8qJDbmpfLlvGiWX+gDDu54mI/Etkitd0Cw6 TCAXmQD4h3ijHZoTefxdpZQoI8rrny9nzv9PlX+Z5xAfj1KIfBy5s1HTDZbJ47ESJlgY YOj4DCiO7mCaxxcuZWlTu02LHwSptzp2tLHij8REAv5R2lW0dYEvpuP6OgEG59m2s1Xj EBrWIuCpbb7M/Q9BszfERDMwqWVrMccldBzHoOsgGzBo5dATVaR9ZoOvJyMgplv7ySfW IhGQ== X-Gm-Message-State: AFuF++kF3SbF7JTOSYkEYM+Q7WYjG0bAtVY+dF0Rdt5mWM8Ey5VdRoJ3 ytumaT4sI5J0nl/6p9XRdeet6TWPWYdPgSkQcS9sMBuLsTTA3oC2RNrGA8pWi0sJiA== X-Gm-Gg: AR+sD11cp1+ZbPZsUM1AFjD6cBlADw2oR7Jma3xOD9pr48DiZsGM9/wYBvdD5Woo9ey gYeJPgFSoafpBlxLeiyyuvWgAfJBjxc2p0TKNBTdbdwxjkECTdBLSuR7M5t8vzuTQBIL+wXIuf7 keGDZ1qSKQHhQXEozrDr0b2BOMT3Tpq8FblBVrZy/XJcS4XDIFfJlcytX4PBfeIQlYCwv/dJSYr gB5uzAeR0yLCM5Q+q79/8EeiayJgXfSBFRdTkWGB2EPA1YNEtR/3ggINqexijaBPBvL5K2EE80O e2mrm2ysqvv7pIalr0pkBkZcWY1ZB81IeluAVOA/bO/9PF2dQUn1uQti8wtPrAxRSJ4s2E7pyoq w5DEkb5dCNG6Ummnu23/PnpnIGP0byVcgQMwF0cCtEjjx7wojBVk8ynkAbULHbvQySQuPMjtq1m /dGFv1yHG+hkOwRtcmcB26O5YsxVHK/3oXb7CWn3FDYCtZ/DCLbwB+ZNz/aIjCNyuPWvLyQiWMy 8i91jhw1icNODcWSE0RDFP4y0lnVu766sEO01IHedoehV9P X-Received: by 2002:a05:600c:34c6:b0:499:5f7a:7ea2 with SMTP id 5b1f17b1804b1-499c19cbbd7mr122720055e9.12.1787503971299; Sun, 23 Aug 2026 09:52:51 -0700 (PDT) Received: from google.com (78.207.190.35.bc.googleusercontent.com. [35.190.207.78]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499c33098besm53780005e9.0.2026.08.23.09.52.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 09:52:50 -0700 (PDT) Date: Sun, 23 Aug 2026 16:52:47 +0000 From: Adrian =?utf-8?Q?Barna=C5=9B?= To: Ard Biesheuvel Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , Catalin Marinas , Will Deacon , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Andrew Morton , Mike Rapoport , Luis Chamberlain , Petr Pavlu , Daniel Gomez , Sami Tolvanen , Aaron Tomlin , Ryan Roberts , Kevin Brodsky , linux-arm-kernel@lists.infradead.org, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org Subject: Re: [RFC PATCH 5/9] arm64: mm: Permit permissions changes on huge vmappings Message-ID: References: <20260822135323.795946-11-ardb+git@google.com> <20260822135323.795946-16-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260822135323.795946-16-ardb+git@google.com> Hi Ard On Sat, Aug 22, 2026 at 03:53:27PM +0200, Ard Biesheuvel wrote: >From: Ard Biesheuvel > >Allow permission changes on huge vmappings in cases where no splitting >is needed (i.e., the region is aligned sufficiently), or when the system >has support for splitting live mappings. > >Signed-off-by: Ard Biesheuvel >--- > arch/arm64/mm/pageattr.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > >diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c >index bbe98ac9ad8c..20ff9cb273c1 100644 >--- a/arch/arm64/mm/pageattr.c >+++ b/arch/arm64/mm/pageattr.c >@@ -169,8 +169,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. >@@ -179,7 +177,16 @@ static int change_memory_common(unsigned long addr, int numpages, > if (!area || > ((unsigned long)kasan_reset_tag((void *)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; >+ >+ /* >+ * Disallow VM_ALLOW_HUGE_VMAP mappings unless the region is PMD >+ * aligned, or splitting live huge mappings is supported. >+ */ >+ if ((area->flags & VM_ALLOW_HUGE_VMAP) && >+ ((start % PMD_SIZE) || (size % PMD_SIZE)) && If I understand the intention here correctly, I don't think it is valid. Even if it is PMD-sized and PMD-aligned, it would still cause a split because the loop below is not using page order, but performs attribute changes page by page. Best regards, Adrian