From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF49B31354F for ; Mon, 20 Jul 2026 18:46:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784573205; cv=none; b=ODjC4cHkGgQ2W47VczhuYfeYicWgVCWqyMvsFP53Bth8LxhGkfcaC6gx2+Vc2KrDAjl9Nkp/ig0nuhMyqYA5CCWshMhWTZHpLltZKD7FV/KlLPRR9zqffYkoAow/pYaJi7ehZJ5WkWwbDZTM+uRpIV0ScwmwgU6z1RLgUgQVHuo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784573205; c=relaxed/simple; bh=glLi0M1+7mIrWNMX9yPHSYqcOtKXvsnk29j2FJ1w5eI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LaATgqjSz/nnWItpQyHcwLf4hvxgIEO+KV9SuUOnL39n1iNrD9brksh+GZ+vbnW5nVdOyKUcoO131gsANPMcShBPmjDRiVowvywErkF8vX3DSHzIWqd6RxmK8BnYE03NuqUIPoxfpL+S1orrWaY78osLq10ODakeSnVb4Zk5NTI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=waT3i14d; arc=none smtp.client-ip=95.215.58.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="waT3i14d" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784573201; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OOPh5TJ7QQOTxu69DpiTtyBt1SBHPlcquVGb26F3iFg=; b=waT3i14dwG8syaSu1aqMzUR8+Dpb70cNQeB16/5E+TQ2yjhDoAHJgRhg4Sfiv74p+QgSPw 6uRBAFyBEe8+H2am6f34vBbmlpEkpWR/Wv2qaWCBCh1bDZl7pp4RZkKQpsDaVd+VqVWIHk 9Xa39pley9bMBExsI065/Ic4TQoqxwY= Date: Mon, 20 Jul 2026 19:46:27 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH RFC v3 2/6] riscv/mm: add untagged_addr_remote_unlocked() To: Rik van Riel Cc: linux-kernel@vger.kernel.org, Andrew Morton , kernel-team@meta.com, David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , linux-riscv@lists.infradead.org References: <20260720115741.239657-1-usama.arif@linux.dev> <13ec2603d5cbfdc493939f182b71e5133c26af54.camel@surriel.com> <46dc1b58-f2de-492a-9da5-a5c429c19a10@linux.dev> <51c0025d2eb885ff1f4775e4d9ffcf34f478f378.camel@surriel.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Usama Arif In-Reply-To: <51c0025d2eb885ff1f4775e4d9ffcf34f478f378.camel@surriel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 20/07/2026 18:34, Rik van Riel wrote: > On Mon, 2026-07-20 at 17:46 +0100, Usama Arif wrote: >> >> >> On 20/07/2026 16:08, Rik van Riel wrote: >>> On Mon, 2026-07-20 at 04:57 -0700, Usama Arif wrote: >>>> On Fri, 17 Jul 2026 13:00:32 -0400 Rik van Riel >>>> >>>> wrote: >>>> >>>> >>>>> >>>>> mm->context.pmlen is set only through PR_SET_TAGGED_ADDR_CTRL >>>>> and >>>>> is stable >>>>> afterwards, so it can be read without the mmap lock, as it >>>>> already >>>>> is from >>>>> untagged_addr() and mm_untag_mask(). >>>>> >>>> >>>> I think it might not be stable? set_tagged_addr_ctrl() can change >>>> it >>>> repeatedly until a CLONE_VM operation sets MM_CONTEXT_LOCK_PMLEN. >>> >>> You're right, ARM tagged addresses seem to work a >> >> ah do you mean RISCV here? > > Ugh, I looked at the wrong one. RISCV is like > x86, with a dynamic (though a limited number > of options?) mask. > > Having said that, won't a process have all of > its VMAs in the masked-off area, so coming in > from a remote process to a valid memory address > should already give us a valid address? > So my understanding from exploring this code is, and hopefully someone in CC from riscv can correct me, for example: Tagged pointer: 0xabcd000012345678 PMLEN 16: 0x0000000012345678 PMLEN 7: 0xffcd000012345678 The target VMA might be at 0x12345678, but applying PMLEN 7 to that tagged pointer does not produce that address. Previously, the order was: Take mmap read lock. Read pmlen. Untag the address. Look up the VMA. Changing PMLEN takes the mmap write lock. The read and write operations were therefore serialized. The new order is: Read pmlen without mmap lock. Untag the address. Attempt the per-VMA lookup. Possibly take mmap lock later. Continue using the already-untagged address. A concurrent PMLEN change can occur between those operations?