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 9236BD5CC9F for ; Wed, 30 Oct 2024 12:00:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2484C8D0003; Wed, 30 Oct 2024 08:00:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F7FA8D0001; Wed, 30 Oct 2024 08:00:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BFE28D0003; Wed, 30 Oct 2024 08:00:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E24B78D0001 for ; Wed, 30 Oct 2024 08:00:20 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 999191C5287 for ; Wed, 30 Oct 2024 12:00:20 +0000 (UTC) X-FDA: 82730125044.30.A5C8FC5 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf29.hostedemail.com (Postfix) with ESMTP id 13202120029 for ; Wed, 30 Oct 2024 11:59:43 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730289458; 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=1N1xdVEPsXRxNtxKZ4JjRSUdmli5ToIexO+r8ZMs53A=; b=Lm0VLTVM2rrwxEORCAGSL+Paj/nNGMpJ6hFy5KeiYQPUUf9k/VySXLCWcGwIp+GM2xCVWo 6FdtILCSLHQjZoLpPAjro3lZhp8K0TWvMSLUNtOnqPj/3TA2Fxl7LtHczEb+Zliq14tQSa Fns8b7NeSk+GMM/zvbghM+9EytBB/iw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730289458; a=rsa-sha256; cv=none; b=m5ljaMyrSKutLdepv+SmGVgl5Y9FB2UM/4hsfhnZ7VOy6MYDqHJZDc2wJF4avvULiVcS1V VQLxgpYQbe6nsa/OdRZoJWz4I+VGaMs7Sc4rRvT43TE+ZUtfYY2rS3Jby/SWEj6zcnDB1b coFn93AAoz3r2wSxG9hw0PSZVfvYZqc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1832AA43BC4; Wed, 30 Oct 2024 11:58:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3683C4CEE3; Wed, 30 Oct 2024 12:00:14 +0000 (UTC) Date: Wed, 30 Oct 2024 12:00:12 +0000 From: Catalin Marinas To: Lorenzo Stoakes Cc: Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Peter Xu , Will Deacon , Mark Brown , "David S . Miller" , Andreas Larsson , "James E . J . Bottomley" , Helge Deller Subject: Re: [PATCH hotfix 6.12 v4 4/5] mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TUID: 0+WlLMvWRpmU X-Stat-Signature: epx4mqr9h5tjqwg6c9oe5hjyebmnktjt X-Rspamd-Queue-Id: 13202120029 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1730289583-245391 X-HE-Meta: U2FsdGVkX1+1R8YQXZ5KWB+AdsWrfd8SKc3DJdUQDFOr50757THZlI1nW6dcHRBF+tC2hMTowIwq6b81DBqxFPguUES4xvZZmoBQVGRAhbvJgPVyLWFN14ErFvYXjADFjdnrNBT5FJd5LdB5LieD5ObJsJ/NAU4PZSzA8eJccBBxsQRTK9e6F6KjgCA0ruChWU4hpXXe7OgsQoka+mGp0c5EcdJ/rUXlfqJW76E/NW/eWX+nSLxHqkeMhciwcpdH/+7IRd76yplxaPgQNm3DoI/oN0elZF9L8dr3MLebDx+PbAN61mOeqSCcEdKlEGtAcNVFRv3qVfVUTHhafGq8S/l53Sjugptp6YatbN+5Vl82Sro4DiWQKUMBX0SfRxdNTKJ2auJEng0IIxPmOyk3PiXdXyPQvmzZsA3Yo8e7dwBo3oBYAySmUkIbKdJCV4a8nClwo6eBG1iq47sGe3GPCciXgxCchd3HSl4s2i8Gi++1EiNGPxQAi+vo0JspxRKbcuZ7zVK9LqYVprd9YawSk/xadf8VYb4Aamjnvo12eBiw7UROMN46EzMWKEkCg+MGW0Qrir7F7seNQ1KJzsg18WOdGvhlg4ukbocyD6H/HjNLQ9w9Ce6zTywPXgsaICOIZWKgK4qwh4pfBWczCoHuHXH26iTYmq+lMsL+YHREoXZnzSbSNqqP2eTLEn446KKxqHU9AWmHqGALPKp4fO13PCwQzezOS7A3Hf29nRmqHTbn9gmi6RJYg56b2RfriHJNKDwepEAU5/Bx5AYmAJDjBC8BvJR0WUhufuo7WuLoHR7ISL2BP2LbWoClkGrWtoO4Ta/L9y4ZTEuycRR0omyPHYes4NBK6SGf1CdOQXQgEnxyVTUqJWv//enYfz+lDtD75hMT3hDEST+oLjvqArMF8IQF8k0I5QQJ4jziCan3vNkI9GBob4H4VlAix/DdSwlJBOfcSDNAEvjgFMQLi6x gC7lbLqH ySBMZy+OfdBMSslg/fU4VgTctGsoIWRvHpjxofYpEV52XbBwPZxPHBM2OFoTOTsjLFon8h/2iy8fV4EF4DhfiLAKY1YNW1uyStT3kaHU+NdlbcUUugX53/96ZAcnMHpOjUf5MzE8gi9qp6uyai8Izh15burwj9rOT5H9DAIDT6+gvfBYdXXCXeNhobA0qk3eu+SKo8D3hGghZYCJsWcJ2WUNwbs+BUZ6h06Vq00b2kiK/lwvNuRqfSQaDvzDYTbuc6H4GaKtbMjEGCr835ENFQ5G6MtMwMSzUpFloDvwv1GLeGPY8tMiU+b/+N1Fa7eZ/vKGMdYAX+K/o1GtrI44LKCch2xZ5i7vEd4GAkTiEU0nPIpKJuRuDxYv5ahk4xoFwB6zdLQuMsiH+BrHfJONAsv6ixsi2yDNcH0r74FHYf3S66EslzrN4e2LTUiynlXHujExwstRGDJP2smmyOaAC0f9X07IvTero3d2IWU+Q3wEpZg2pW5ww5moYkQakRwXY4HwFttDX5vPGEl0= 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 Tue, Oct 29, 2024 at 06:11:47PM +0000, Lorenzo Stoakes wrote: > Currently MTE is permitted in two circumstances (desiring to use MTE having > been specified by the VM_MTE flag) - where MAP_ANONYMOUS is specified, as > checked by arch_calc_vm_flag_bits() and actualised by setting the > VM_MTE_ALLOWED flag, or if the file backing the mapping is shmem, in which > case we set VM_MTE_ALLOWED in shmem_mmap() when the mmap hook is activated > in mmap_region(). > > The function that checks that, if VM_MTE is set, VM_MTE_ALLOWED is also set > is the arm64 implementation of arch_validate_flags(). > > Unfortunately, we intend to refactor mmap_region() to perform this check > earlier, meaning that in the case of a shmem backing we will not have > invoked shmem_mmap() yet, causing the mapping to fail spuriously. > > It is inappropriate to set this architecture-specific flag in general mm > code anyway, so a sensible resolution of this issue is to instead move the > check somewhere else. > > We resolve this by setting VM_MTE_ALLOWED much earlier in do_mmap(), via > the arch_calc_vm_flag_bits() call. > > This is an appropriate place to do this as we already check for the > MAP_ANONYMOUS case here, and the shmem file case is simply a variant of the > same idea - we permit RAM-backed memory. > > This requires a modification to the arch_calc_vm_flag_bits() signature to > pass in a pointer to the struct file associated with the mapping, however > this is not too egregious as this is only used by two architectures anyway > - arm64 and parisc. > > So this patch performs this adjustment and removes the unnecessary > assignment of VM_MTE_ALLOWED in shmem_mmap(). > > Suggested-by: Catalin Marinas > Reported-by: Jann Horn > Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails") > Cc: stable > Signed-off-by: Lorenzo Stoakes Thanks for respinning this. FTR, Reviewed-by: Catalin Marinas > @@ -151,13 +152,13 @@ calc_vm_prot_bits(unsigned long prot, unsigned long pkey) > * Combine the mmap "flags" argument into "vm_flags" used internally. > */ > static inline unsigned long > -calc_vm_flag_bits(unsigned long flags) > +calc_vm_flag_bits(struct file *file, unsigned long flags) > { > return _calc_vm_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN ) | > _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED ) | > _calc_vm_trans(flags, MAP_SYNC, VM_SYNC ) | > _calc_vm_trans(flags, MAP_STACK, VM_NOHUGEPAGE) | > - arch_calc_vm_flag_bits(flags); > + arch_calc_vm_flag_bits(file, flags); Nitpick (but please ignore, Andrew picked them up already): one space alignment off. -- Catalin