From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0D2D6372B3A for ; Tue, 17 Mar 2026 09:29:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773739791; cv=none; b=Nhj4QSspqeZUULQ7+UO4TrfHk2MryeQ8PRq3siFqlWRJROB90Xbu9VhhNI6th8qpG5sm2I4144bqx81e00Z36JlLXHdhM9zEIMpTmtyBYjsDNzRiu+F1bUW87rSujdDafX67gHvz4+QQFu1ncvnPwW1VBfNjo7KazTdbAdvGGjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773739791; c=relaxed/simple; bh=SCppVwOYrQuBaxEJcWga0mZ27LJmOENJoPVC9X9OwH0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gdOhd1PQbfz5szor4Ox4QD5Nr1vYEMDiLT613vzptSWL3jTsEFK8NufztdcNWw0lzMDSI6JBbUq2JiW6n0s5HZYgZIfimQtCZkLYzvVtDkW0peqZq+GBLj/VRjQLDeMIV2WM4Z45xke92bbjJ7SIkw7G1Sz/Mq09UYyI4kPOhfw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 475C61476; Tue, 17 Mar 2026 02:29:43 -0700 (PDT) Received: from [10.57.60.143] (unknown [10.57.60.143]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BC3B93F778; Tue, 17 Mar 2026 02:29:46 -0700 (PDT) Message-ID: <6c0ed052-5f3c-405a-b53f-4ea21a24479d@arm.com> Date: Tue, 17 Mar 2026 10:29:44 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 0/5] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full To: Ryan Roberts , Yang Shi , Jinjiang Tu , catalin.marinas@arm.com, will@kernel.org, akpm@linux-foundation.org, david@redhat.com, lorenzo.stoakes@oracle.com, ardb@kernel.org, dev.jain@arm.com, scott@os.amperecomputing.com, cl@gentwo.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20250917190323.3828347-1-yang@os.amperecomputing.com> <0b2a4ae5-fc51-4d77-b177-b2e9db74f11d@huawei.com> <0a740020-4780-4156-a9c5-f8b4ada9c8c0@os.amperecomputing.com> <4ad2ea40-b23b-4231-a0de-585b205865c5@arm.com> <9dded616-989b-4846-8596-1c45a6304d36@arm.com> From: Kevin Brodsky Content-Language: en-GB In-Reply-To: <9dded616-989b-4846-8596-1c45a6304d36@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 17/03/2026 10:13, Ryan Roberts wrote: >>>> Another option would be to initially map by pte then collapse to >>>> block mappings >>>> once we have determined that all cpus support BBML2_NOABORT. We >>>> originally opted >>>> not to do that because it's a tax on symetric systems. But we could >>>> throw in the >>>> towel if it's the least bad solution we can come up with for solving >>>> this. I >>>> think it might help some of Kevin's use cases too? >>> May be an option too. When we discussed this there was no usecase for >>> direct mapping collapse. But if we can have multiple usecases, it may >>> be worth it. > I could imagine that if user space creates and destroys lots of secretmem areas, > then it will completely split the linear map to ptes and that will never recover > currently. So I think in the long term, having the ability to collapse would be > useful. I just don't particularly like forcing symetric systems to map by pte > initially (which is slow) only to collapse later (which will cost even more > time). But it does feel inherrently more robust. Now that you spell it out, I'm realising this would actually make things pretty complicated for protected page tables. In that series, page tables for the linear map are allocated by a separate memblock-based allocator [1], tracking the allocated ranges to set their pkey later. There's a strong assumption that these page tables are never freed. If we initially PTE-mapped the linear map and then later collapsed it, that assumption clearly wouldn't hold. It could be handled by poking holes in the tracked ranges, but it gets ugly and increases fragmentation. On the whole I'm not sure there's a sufficiently good argument to always have the linear map PTE-mapped initially. - Kevin [1] https://lore.kernel.org/linux-hardening/20260227175518.3728055-19-kevin.brodsky@arm.com/