Re: [PATCH RFC v3 2/6] riscv/mm: add untagged_addr_remote_unlocked()

[Usama Arif]

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/<pid>/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?