Skip to contentSkip to conversation

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

DISCUSSION [email protected] 4 participants 8 messages Jun 18, 2025 – Jun 19, 2025 RISC-V

lore
Share & tools
lore

[email protected]

author
#0 lore raw

This program on risc-v:

main(){
futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);
}

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
[email protected]

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

#1 lore raw
Quoted 9 lines · On Wed, Jun 18, 2025 at 07:10:28AM -0400, [email protected] wrote:

This program on risc-v:

main(){
futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);
}

results in:

BUG: Bad page state in process a.out  pfn:81500

I cannot reproduce this issue. Can you please share your .config?

Also, your kernel seems to have some commits on top. Are you sure none of those is the reason?

Best regards,
Nam

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

maintainer
#2 lore raw
Quoted 7 lines · On Wed, 18 Jun 2025 06:25:59 PDT (-0700), [email protected] wrote:
Quoted 6 lines · On Wed, Jun 18, 2025 at 07:10:28AM -0400, [email protected] wrote:

This program on risc-v:

main(){
futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);
}

Quoted 5 lines
Quoted 3 lines

results in:

BUG: Bad page state in process a.out  pfn:81500

I cannot reproduce this issue. Can you please share your .config?

It's also not reproducing for me -- or even compiling for that matter, but I stuck one that compiles over at <https://github.com/palmer-dabbelt/palmer-tests/blob/main/rtm-futex.c> (I figured this was a good excuse to start piling up some tests).

Quoted 2 lines

Also, your kernel seems to have some commits on top. Are you sure none of those is the reason?

This is on my fixes branch right now, with defconfig + CONFIG_DEBUG_VM=y. So maybe it's one of these patches, or moybe it's some other configuration thing?

I'm also running this in QEMU virt, rv64gc, smp=4 (in case that matters). I've got a buildroot-based userspace with glibc.

Quoted 8 lines

Best regards,
Nam

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

author
#4 lore raw
In reply to Nam Cao

If I build a kernel from clean source with the default config, it doesn't exhibit this problem.

But if I then modify the default config by turning off CONFIG_COMPAT, and turning on CONFIG_DEBUG_VM, then I do get the crash, with

futex((void*)0x1ffffff80c20000, FUTEX_WAIT, 0, 0, 0, 0); // bbb

I had to search for the address, with

  unsigned long base = 0x1ffffff80000000;
  for(unsigned long inc = 0; ; inc += 4096){
    printf("%lx\n", base+inc);
    futex((void*)(base+inc), FUTEX_WAIT, 0, 0, 0, 0);
  }

I've attached two config files: one is what I was using when I originally submitted this issue, and the second is the default config without COMPAT and with DEBUG_VM.

Robert

Quoted 19 lines

Date: Wed, 18 Jun 2025 15:25:59 +0200
From: Nam Cao <[email protected]>
To: [email protected]
Cc: Paul Walmsley <[email protected]>,
Palmer Dabbelt <[email protected]>, Albert Ou <[email protected]>, Alexandre Ghiti <[email protected]>, [email protected]
Subject: Re: futex(0x1ffffff81300000) on risc-v -> mm panic

Quoted 9 lines · On Wed, Jun 18, 2025 at 07:10:28AM -0400, [email protected] wrote:

This program on risc-v:

main(){
futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);
}

results in:

BUG: Bad page state in process a.out  pfn:81500
Quoted 7 lines

I cannot reproduce this issue. Can you please share your .config?

Also, your kernel seems to have some commits on top. Are you sure none of those is the reason?

Best regards,
Nam

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

#3 lore raw
In reply to Palmer Dabbelt
Quoted 19 lines · Palmer Dabbelt
Quoted 7 lines · On Wed, 18 Jun 2025 06:25:59 PDT (-0700), [email protected] wrote:
Quoted 6 lines · On Wed, Jun 18, 2025 at 07:10:28AM -0400, [email protected] wrote:

This program on risc-v:

main(){
futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);
}

Quoted 5 lines
Quoted 3 lines

results in:

BUG: Bad page state in process a.out  pfn:81500

I cannot reproduce this issue. Can you please share your .config?

It's also not reproducing for me -- or even compiling for that matter, but I stuck one that compiles over at
<https://github.com/palmer-dabbelt/palmer-tests/blob/main/rtm-futex.c> (I figured this was a good excuse to start piling up some tests).

Quoted 6 lines
Quoted 2 lines

Also, your kernel seems to have some commits on top. Are you sure none of those is the reason?

This is on my fixes branch right now, with defconfig + CONFIG_DEBUG_VM=y. So maybe it's one of these patches, or moybe it's some other configuration thing?

I can reproduce this with QEMU and Debian trixie. defconfig + DEBUG_VM=y is enough. I have to "search for the address", as OP showed in the other email, because 0x1ffffff81300000 doesn't trigger any issue for me.

I can also reproduce on 6.14 and 6.15, so not a recent regression.

I will look closer tomorrow.

Best regards,
Nam

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

reviewer
#5 lore raw
In reply to [email protected]
Quoted 4 lines · On 6/18/25 12:10, [email protected] 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

Quoted 61 lines

}

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
Quoted 7 lines

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
[email protected]

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

author
#6 lore raw

Alex,

Deleting

  #define TASK_SIZE_MAX  LONG_MAX

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

Robert

Quoted 20 lines

Date: Thu, 19 Jun 2025 14:35:21 +0200
Subject: Re: futex(0x1ffffff81300000) on risc-v -> mm panic
To: [email protected], Paul Walmsley <[email protected]>,
Palmer Dabbelt <[email protected]>, Albert Ou <[email protected]>
Cc: [email protected]
From: Alexandre Ghiti <[email protected]>

Quoted 4 lines · On 6/18/25 12:10, [email protected] 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.

Quoted 77 lines

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

Quoted 68 lines

}

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
[email protected]

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

#7 lore raw
In reply to Alexandre Ghiti
Quoted 10 lines · Alexandre Ghiti
Quoted 4 lines · On 6/18/25 12:10, [email protected] 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.

Quoted 6 lines

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?

Yeah my git bisect said the same thing. At first I thought that commit just uncovered some deeper problem; but staring at it, I think that is the bug.

Just send a patch.

Best regards,
Nam

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv