From: Omar Sandoval <osandov@osandov.com>
To: Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
linux-riscv@lists.infradead.org
Cc: linux-debuggers@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH] riscv: fix vmemmap and vmalloc offsets in /proc/kcore
Date: Thu, 5 Feb 2026 12:31:20 -0800 [thread overview]
Message-ID: <5273041dacfde780bbc917660537783c354e0598.1770323325.git.osandov@fb.com> (raw)
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.
Thanks,
Omar
arch/riscv/include/asm/pgtable-64.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
index 6e789fa58514..a52d60dd80fc 100644
--- a/arch/riscv/include/asm/pgtable-64.h
+++ b/arch/riscv/include/asm/pgtable-64.h
@@ -403,4 +403,7 @@ static inline pte_t pmd_pte(pmd_t pmd);
static inline pte_t pud_pte(pud_t pud);
#endif
+#define kc_vaddr_to_offset(v) ((v) & ((1UL << VA_BITS) - 1))
+#define kc_offset_to_vaddr(o) ((o) | ~((1UL << VA_BITS) - 1))
+
#endif /* _ASM_RISCV_PGTABLE_64_H */
--
2.52.0
next reply other threads:[~2026-02-05 20:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-05 20:31 Omar Sandoval [this message]
2026-04-27 20:48 ` [PATCH] riscv: fix vmemmap and vmalloc offsets in /proc/kcore Omar Sandoval
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5273041dacfde780bbc917660537783c354e0598.1770323325.git.osandov@fb.com \
--to=osandov@osandov.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=kernel-team@fb.com \
--cc=linux-debuggers@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox