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 4632A229B1F for ; Wed, 17 Sep 2025 16:28:06 +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=1758126488; cv=none; b=Kd8HYjd83Gr/KHUmnTcpFRFk+mTkRUKEil5LPEM8O4Df0A90ed3SQJUlKc6lZjyqLigKch8vBIxb3JMVoFGjH2J/yjGnj6t/x7YSQAqwSPNdYi2brSaEGvouOLw4nlPqIv95a8ngaospnpjhCf+3QRelJyTem/n4h1o2O4iOveg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758126488; c=relaxed/simple; bh=pebIO8LxpQm+Zj3FiHFYPL6YW0OTGI36pvolWFTfS2A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cqMfCORc+nfBIgzfbMXTCRVqWuystpZhHZ/CPkJO2viJIROvdypcFdPAYwSQXtpBaMRCU9d5cREyrjH0DNxu2IEL7rKw6CD+GYfxsGXHNLqylp1gKJyAQnB3EDZ9UWGlx687ohaiEhOeH5BQEjtmS4OsbtxaZeJChB9xEaTzlnM= 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 351AF267F; Wed, 17 Sep 2025 09:27:57 -0700 (PDT) Received: from [10.57.80.26] (unknown [10.57.80.26]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B07303F673; Wed, 17 Sep 2025 09:28:03 -0700 (PDT) Message-ID: Date: Wed, 17 Sep 2025 17:28:02 +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 v7 0/6] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full Content-Language: en-GB To: Yang Shi , Dev Jain , Catalin Marinas , Will Deacon , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Ard Biesheuvel , scott@os.amperecomputing.com, cl@gentwo.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20250829115250.2395585-1-ryan.roberts@arm.com> <612940d2-4c8e-459c-8d7d-4ccec08fce0a@os.amperecomputing.com> <1471ea27-386d-4950-8eaa-8af7acf3c34a@arm.com> <39c2f841-9043-448d-b644-ac96612d520a@os.amperecomputing.com> <8c363997-7b8d-4b54-b9b0-1a1b6a0e58ed@arm.com> <4aa4eedc-550f-4538-a499-504dc925ffc2@os.amperecomputing.com> <1cfda234-1339-4d83-bd87-b219fbd72664@arm.com> <55a79826-48e3-41c0-8dbd-b6398e7e49a6@os.amperecomputing.com> <92719b15-daf8-484f-b0db-72e23ae696ad@os.amperecomputing.com> From: Ryan Roberts In-Reply-To: <92719b15-daf8-484f-b0db-72e23ae696ad@os.amperecomputing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yang, Sorry for the slow reply; I'm just getting back to this... On 11/09/2025 23:03, Yang Shi wrote: > Hi Ryan & Catalin, > > Any more concerns about this? I've been trying to convince myself that your assertion that all users that set the VM_FLUSH_RESET_PERMS also call set_memory_*() for the entire range that was returned my vmalloc. I agree that if that is the contract and everyone is following it, then there is no problem here. But I haven't been able to convince myself... Some examples (these might intersect with examples you previously raised): 1. bpf_dispatcher_change_prog() -> bpf_jit_alloc_exec() -> execmem_alloc() -> sets VM_FLUSH_RESET_PERMS. But I don't see it calling set_memory_*() for rw_image. 2. module_memory_alloc() -> execmem_alloc_rw() -> execmem_alloc() -> sets VM_FLUSH_RESET_PERMS (note that execmem_force_rw() is nop for arm64). set_memory_*() is not called until much later on in module_set_memory(). Another error in the meantime could cause the memory to be vfreed before that point. 3. When set_vm_flush_reset_perms() is set for the range, it is called before set_memory_*() which might then fail to split prior to vfree. But I guess as long as set_memory_*() is never successfully called for a *sub-range* of the vmalloc'ed region, then for all of the above issues, the memory must still be RW at vfree-time, so this issue should be benign... I think? In summary this all looks horribly fragile. But I *think* it works. It would be good to clean it all up and have some clearly documented rules regardless. But I think that could be a follow up series. > Shall we move forward with v8? Yes; Do you wnat me to post that or would you prefer to do it? I'm happy to do it; there are a few other tidy ups in pageattr.c I want to make which I spotted. > We can include the > fix to kprobes in v8 or I can send it separately, either is fine to me. Post it on list, and I'll also incorporate into the series. > Hopefully we can make v6.18. It's probably getting a bit late now. Anyway, I'll aim to get v8 out tomorrow or Friday and we will see what Will thinks. Thanks, Ryan > > Thanks, > Yang >