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

[Rik van Riel <riel@surriel.com>]

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?

Does that reproduce the failure case, without
any locking changes?
> 

> 

-- 
All Rights Reversed.