From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) (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 BCF56426687 for ; Mon, 20 Jul 2026 19:39:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784576385; cv=none; b=q7BOEVwZP72VBIzvyrxdvWI9zQAGtbg5NhfdSgnxUekNHkgGauOrKpOC32YnnQ+4aGu1GzdMCIVJx8sa7WvxxIWqLkk0rLeMEyc9iLieebEKmiIGrmKeEHR57mKq+GyXbrjHoZp5p1QlN4VuFzBbONUs2f24+Ga7ARJJ/WaB+68= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784576385; c=relaxed/simple; bh=0AoPYaek1zIdCaBn/7OIXheVcLvsGEkh1REHHktsBMY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MG38KE/1yymY6gpcJ4QIap/Y+hTkWcMbUFyAfYqXu2jr9sFx5tch8cP7to6NHWvfk41fS9YVg742SuP3YDvJyC+Q5/VTgcLtL0h2AAKQDW09gu1XBBJ0mscT29xn2f3dfGwwMyexHdMOHX3TQ3koboprjRA95T7a5mrXK5J6Ba8= 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=UEQylVYa; arc=none smtp.client-ip=91.218.175.173 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="UEQylVYa" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784576381; 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=/qp0qmX7/lG+2iV/7px+x4IwYJSrixYtqlMKjlDaa2k=; b=UEQylVYahUPHKpHwcBPg9WnwTJ4SqNhc1/GHwwewzeeQTWeJBDq8dQc33sgPNQ5xVM+gpZ rJOtWPzp/R8wroyp2kpT60GUb6BG9zG8ibFxKCiR1JzYty50EqpxtsmyOXaG2NLaOYuYQx jyRfm1vXIHd4Ko6tOlB2ZVX3pIu23H8= Date: Mon, 20 Jul 2026 20:39:37 +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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 20/07/2026 20:21, Rik van Riel wrote: > On Mon, 2026-07-20 at 19:46 +0100, Usama Arif wrote: >> >> 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? > > I suppose it could, but what are the possible outcomes here? > > - We fail to untag the address, the vma lookup > fails, and we fail to access memory. > > - The address is already untagged, maps to a > VMA, and the access succeeds. > > Are there any others? > > The VMAs of the process need to be in the bottom > part of the address space, right? The part where > untagged addresses sit. > > For things like /proc//cmdline we should > automatically get an address without any of the > high bits set. > > For things like ptrace peek / poke, BPF process > accesses, and others, I really do not know if > those could get tagged addresses... > > What are the failures we need to protect against? > > What if something comes in with a tagged address, > but the process disables tagging while that > something waits for the mmap_lock? So I think the above question is what needs to be answered. A tagged pointer can become invalid if PMLEN changes before the old mmap-locked lookup too. The mmap lock only defined whether the lookup observed the old or new mode. For VMA as you said, it should be ok. I don't know about others. I think it would be best to get input from RISC-V folks for this. Hopefully its ok.. If it is ok, then all that would be need to be done is to just remove in the commit message that pmlen is stable. > > Does that reproduce the failure case, without > any locking changes?