futex(0x1ffffff81300000) on risc-v -> mm panic

[rtm at csail.mit.edu]

Alex,

Deleting 

  #define TASK_SIZE_MAX  LONG_MAX

from arch/riscv/include/asm/pgtable.h does indeed make the problem
go away.

Robert

> Date: Thu, 19 Jun 2025 14:35:21 +0200
> Subject: Re: futex(0x1ffffff81300000) on risc-v -> mm panic
> To: rtm at csail.mit.edu, Paul Walmsley <paul.walmsley at sifive.com>,
>         Palmer Dabbelt <palmer at dabbelt.com>, Albert Ou <aou at eecs.berkeley.edu>
> Cc: linux-riscv at lists.infradead.org
> From: Alexandre Ghiti <alex at ghiti.fr>
> 
> On 6/18/25 12:10, rtm at csail.mit.edu wrote:
> > This program on risc-v:
> >
> > main(){
> >    futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);
> 
> 
> This address is far beyond what userspace is supposed to be able to
> access, even in sv57, see Documentation/arch/riscv/vm-layout.rst.
> 
> The problem is that access_ok() lets it go through and then gup
> returns a kernel mapping, which isn't good at all.
> 
> I can't reproduce the issue, but it seems like commit ad5643cf2f69
> ("riscv: Define TASK_SIZE_MAX for __access_ok()") is the culprit, can
> you try reverting it?
> 
> Thanks,
> 
> Alex
> 
> 
> > }
> >
> > results in:
> >
> > BUG: Bad page state in process a.out  pfn:81500
> > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81500
> > flags: 0x2000(reserved|zone=0)
> > raw: 0000000000002000 ff1c000000054008 ff1c000000054008 0000000000000000
> > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> > page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
> > Modules linked in:
> > CPU: 0 UID: 0 PID: 105 Comm: a.out Not tainted 6.16.0-rc2-00067-gb61aa0e0059b #566 NONE
> > Hardware name: riscv-virtio,qemu (DT)
> > Call Trace:
> > [<ffffffff80025b62>] dump_backtrace+0x1c/0x24
> > [<ffffffff800023b8>] show_stack+0x28/0x34
> > [<ffffffff800205d2>] dump_stack_lvl+0x48/0x66
> > [<ffffffff80020604>] dump_stack+0x14/0x1c
> > [<ffffffff80262098>] bad_page+0x118/0x15c
> > [<ffffffff80264e96>] __free_frozen_pages+0x494/0x650
> > [<ffffffff80266fe2>] free_frozen_pages+0xe/0x16
> > [<ffffffff8020926c>] __folio_put+0x60/0xae
> > [<ffffffff800ec23a>] get_futex_key+0x2da/0x44e
> > [<ffffffff800f0474>] futex_wait_setup+0x52/0x23a
> > [<ffffffff800f06da>] __futex_wait+0x7e/0xd8
> > [<ffffffff800f0782>] futex_wait+0x4e/0xbc
> > [<ffffffff800ed3a0>] do_futex+0x74/0x100
> > [<ffffffff800ed4f4>] __riscv_sys_futex+0xc8/0x148
> > [<ffffffff811e4930>] do_trap_ecall_u+0x84/0x11a
> > [<ffffffff811f0b0e>] handle_exception+0x146/0x152
> > Disabling lock debugging due to kernel taint
> >
> > and after running this program a few more times:
> >
> > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81500
> > flags: 0x2000(reserved|zone=0)
> > raw: 0000000000002000 ff1c000000054008 ff1c000000054008 0000000000000000
> > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> > page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
> > ------------[ cut here ]------------
> > kernel BUG at ./include/linux/mm.h:1034!
> > Kernel BUG [#1]
> > Modules linked in:
> > CPU: 0 UID: 0 PID: 110 Comm: a.out Tainted: G    B               6.16.0-rc2-00067-gb61aa0e0059b #566 NONE
> > Tainted: [B]=BAD_PAGE
> > Hardware name: riscv-virtio,qemu (DT)
> > epc : get_futex_key+0x23c/0x44e
> >   ra : get_futex_key+0x23c/0x44e
> > ...
> > [<ffffffff800ec19c>] get_futex_key+0x23c/0x44e
> > [<ffffffff800f0474>] futex_wait_setup+0x52/0x23a
> > [<ffffffff800f06da>] __futex_wait+0x7e/0xd8
> > [<ffffffff800f0782>] futex_wait+0x4e/0xbc
> > [<ffffffff800ed3a0>] do_futex+0x74/0x100
> > [<ffffffff800ed4f4>] __riscv_sys_futex+0xc8/0x148
> > [<ffffffff811e4930>] do_trap_ecall_u+0x84/0x11a
> > [<ffffffff811f0b0e>] handle_exception+0x146/0x152
> > Code: bdad a597 017c 8593 fa65 8526 7097 0014 80e7 a4a0 (9002) 8785
> > ---[ end trace 0000000000000000 ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> >
> > get_futex_key() calls get_user_pages_fast(), which returns a
> > PG_reserved page in one of the reserve_bootmem_region() areas. Beyond
> > that I do not understand the situation.
> >
> > Robert Morris
> > rtm at mit.edu
> >