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 48454D5CCA1 for ; Wed, 30 Oct 2024 12:39:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CF866B00B4; Wed, 30 Oct 2024 08:39:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87D416B00B5; Wed, 30 Oct 2024 08:39:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71E036B00B8; Wed, 30 Oct 2024 08:39:40 -0400 (EDT) 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 51A416B00B4 for ; Wed, 30 Oct 2024 08:39:40 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C0BB3A8886 for ; Wed, 30 Oct 2024 12:39:39 +0000 (UTC) X-FDA: 82730224122.22.42464D4 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf29.hostedemail.com (Postfix) with ESMTP id 841C512001F for ; Wed, 30 Oct 2024 12:39:03 +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=1730291897; 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=IwZKSOHM+Pn+VFNSE44W1Y/gQUyeQVdBvVdpIyVKFqc=; b=EvIPzJXb8Vh8HO1GioSPlI2+BkhDKUweMnylCmVwyU4c4trPARJMKfl6jf7kjFoJRoXDTq mnOKsmk1iurt+35k77o6r7/GeMt6HrU2HMl8YHq8DEUOg+QmEo0JK5mqHyMl8jQkrfkKKp TbSCKf1ciDPjmmNNQ5tTdMDhYaFOSpg= 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) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730291897; a=rsa-sha256; cv=none; b=pIEqdr1TlzWbZoWQnX5wCdJBEMqEsqZ/5+SD+bzrqAQjydG9q/Q+zNbj7QtHb5jb05iT/z bbEy37QlsCc0DoriC8YVb7WvZTrK5XsrgrXKvGEEALwL5JorZYMYUMVEcUwURUMP8vZwPo Pbmop2ccrE1fpP4Lz/uCfXJoqnNEoxc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id A543CA43C3F; Wed, 30 Oct 2024 12:37:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37EE5C4CEE3; Wed, 30 Oct 2024 12:39:34 +0000 (UTC) Date: Wed, 30 Oct 2024 12:39:31 +0000 From: Catalin Marinas To: Lorenzo Stoakes Cc: Vlastimil Babka , Andrew Morton , "Liam R . Howlett" , 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 , Yang Shi Subject: Re: [PATCH hotfix 6.12 v4 4/5] mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling Message-ID: References: <3f184fad-e0da-470a-888e-70a17419e206@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f184fad-e0da-470a-888e-70a17419e206@lucifer.local> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 841C512001F X-Stat-Signature: hkfe6qmt9pgjes7jhgtg6aiy5944d1ex X-HE-Tag: 1730291943-718105 X-HE-Meta: U2FsdGVkX19MqqCDPqcFOTeYX7ho6ux5GDNQLWrIxLEZMqCjNugdxR7/9XT/OsS6dJT4w1u5CY4n7JkgkpBHnAydu+mH9hMmIKJrLToaJ+5O60QUtfE4p1nG0nauqy+Z0MevYK6IuJ4Xz/cdh19qVT+9rVv9nbe/wCA0PWQm/zHBSZcXVdiGfO7slGloE4wb5qbb19V/I6mkFnMHGjeRjGixN+X5x+kijDumG+eMq74DctV90Zp15OOcRsCmDp/N0j1MTOV3Oor8GnBmQ1aG8WcSBXBFtuw/VqeURrgnJzVwjAJl7Ic5w+rrj+YUvU6/SWWnE009rhyLs8KfvMIW2ISdrfLOeg4j/Yrnk1urGitRFfzaL9Duno3Sz2257jnXSDs220AaaI5M3n8qtQX/KVJZ3Nu4rVpKS/ECggsx97dL5VnWYJ16QTJYwlMAXM5Np17zvX1Fc/M9Pum6ganC6uwxIsLVFTZo6zNFuppJBsBTimEbJGKZ8QpmWrsW7/WAdjOrKRM5H+f6UTsruA/zZ0DVCFE6ju97aXA6rlhe1q+xHyctVWc9IKxoS2HvnyLxvjCPw5qpEbCiqaMe519pXbm3gB3HAgjf+Bd9AxhUs3ht5jdi0QqMiNSgZth+K3zOMwslyPa+gsa1fL/EEXalkGV8ofODPpqmtxoXubS8HAbOGM3m+aVK/th1LjXB8gRho2ZZTN9+oyfh1nB4NTiWzwwJGvgV09RnL1Aku7Dw9yvKn0NQoMoZ44oUKU7K89A2It1ecbSDf1pIVHvXAzGIM5dHp0b8rYYnF3h6gHFWT8uxGAr1vJFftar6I59OqK+jAiS0MsaMMICBPitfZu1GxXiiSoVxz3AA1tdP3yd3H0niQ9K27ddgF9Q68ItYsogYhmzo7kzpGFfm+k3gBbT3nO1nGUtzEovzhWli8tyHgCDrYajAdzKhMeWbL6V3MH0LY9WjMGZ8SF2Gt2D5t6H 2zyulaur V8fWitHx5bgyex0ZlP2o2b/zyv9Mwsgqf8fJFAUOrUAabGf9wRAes5Kyb/TrRuBRsTRsa82hJONvK5IxkwCfn/ewx+UyOwlLVuu2QFKM3ErMbapO9T9nRtPXpxIj+yGXw/IZ7ynOZqEAuXGkGWl6NDs6D7MpeArXODShYNvvHbUQ6t++4TlbRX0EXZVsl0VzYwDNJQlCRMGFpxHT+UvtscdgEyHUyLNt9DAOEghm9dXTn8+Sy3FAVTtkLTCJslovFy4jYHkl9Uc6k+n0HnlFDbm/j6qR1k3rCzGR4Gfm2szLuYusozh9eO5T2Uiy00n3lKRI6fY5XFDetCuU4OEtVUetZaEHVdUglxgxxJ+SWOdiyEHyVjGuu8x0lMGkIclZGR+fsYueTPVFJQS0= 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 Wed, Oct 30, 2024 at 11:53:06AM +0000, Lorenzo Stoakes wrote: > On Wed, Oct 30, 2024 at 12:09:43PM +0100, Vlastimil Babka wrote: > > On 10/30/24 11:58, Catalin Marinas wrote: > > > On Wed, Oct 30, 2024 at 10:18:27AM +0100, Vlastimil Babka wrote: > > >> On 10/29/24 19:11, Lorenzo Stoakes wrote: > > >> > --- a/arch/arm64/include/asm/mman.h > > >> > +++ b/arch/arm64/include/asm/mman.h > > >> > @@ -6,6 +6,8 @@ > > >> > > > >> > #ifndef BUILD_VDSO > > >> > #include > > >> > +#include > > >> > +#include > > >> > #include > > >> > > > >> > static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot, > > >> > @@ -31,19 +33,21 @@ static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot, > > >> > } > > >> > #define arch_calc_vm_prot_bits(prot, pkey) arch_calc_vm_prot_bits(prot, pkey) > > >> > > > >> > -static inline unsigned long arch_calc_vm_flag_bits(unsigned long flags) > > >> > +static inline unsigned long arch_calc_vm_flag_bits(struct file *file, > > >> > + unsigned long flags) > > >> > { > > >> > /* > > >> > * Only allow MTE on anonymous mappings as these are guaranteed to be > > >> > * backed by tags-capable memory. The vm_flags may be overridden by a > > >> > * filesystem supporting MTE (RAM-based). > > >> > > >> We should also eventually remove the last sentence or even replace it with > > >> its negation, or somebody might try reintroducing the pattern that won't > > >> work anymore (wasn't there such a hugetlbfs thing in -next?). > > > > > > I agree, we should update this comment as well though as a fix this > > > patch is fine for now. > > > > > > There is indeed a hugetlbfs change in -next adding VM_MTE_ALLOWED. It > > > should still work after the above change but we'd need to move it over > > > > I guess it will work after the above change, but not after 5/5? > > > > > here (and fix the comment at the same time). We'll probably do it around > > > -rc1 or maybe earlier once this fix hits mainline. > > > > I assume this will hopefully go to rc7. > > To be clear - this is a CRITICAL fix that MUST land for 6.12. I'd be inclined to > try to get it to an earlier rc-. Ah, good point. So after this series is merged at rc6/rc7, the new MTE+hugetlbfs in -next won't work. Not an issue, it can be sorted out later. > > > I don't think we have > > > an equivalent of shmem_file() for hugetlbfs, we'll need to figure > > > something out. > > > > I've found is_file_hugepages(), could work? And while adding the hugetlbfs > > change here, the comment could be adjusted too, right? > > Right but the MAP_HUGETLB should work to? Can we save such changes that > alter any kind of existing behaviour to later series? > > As this is going to be backported (by me...!) and I don't want to risk > inadvertant changes. MAP_HUGETLB and is_file_hugepages() fixes can go in after 6.13-rc1. This series is fine as is, we wouldn't backport any MAP_HUGETLB changes anyway since the flag check wasn't the only issue that needed addressing for hugetlb MTE mappings. -- Catalin