Re: [PATCH] riscv: fix vmemmap and vmalloc offsets in /proc/kcore

[Omar Sandoval <osandov@osandov.com>]

On Thu, Feb 05, 2026 at 12:31:20PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
> 
> kc_vaddr_to_offset() maps a kernel virtual address to its file offset in
> /proc/kcore. The default definition is (address - PAGE_OFFSET). However, on
> RISC-V, the vmemmap and vmalloc regions are below PAGE_OFFSET, so the computed
> offsets for those regions are negative and wrap around to a large u64:
> 
>   # readelf -l /proc/kcore
>   ...
>   Program Headers:
>     Type           Offset             VirtAddr           PhysAddr
>                    FileSiz            MemSiz              Flags  Align
>   ...
>     LOAD           0xffc0000000002000 0xff20000000000000 0xffffffffffffffff
>                    0x0040000000000000 0x0040000000000000  RWE    0x1000
>   ...
> 
> When userspace applications like drgn attempt to read from that offset, it
> overflows an loff_t and results in EINVAL.
> 
> Fix it by defining an alternate kc_vaddr_to_offset() that masks off the
> high bits, which is what x86-64 does, too.
> 
> Fixes: 07037db5d479 ("RISC-V: Paging and MMU")
> Cc: stable@vger.kernel.org
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
> Based on Linus' tree as of 8fdb05de0e2db89d8f56144c60ab784812e8c3b7.
> 
> This method doesn't work for riscv32 since VA_BITS == BITS_PER_LONG
> there. But, I think riscv32 can get away with the wrapped 32-bit
> integers as long as userspace is using _FILE_OFFSET_BITS=64. I don't
> have a riscv32 userspace environment available to test it.

Ping. I've been carrying this patch for my test builds for a few
releases with no problems. It'd be great to get it resolved.

Thanks,
Omar

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv