* [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address
@ 2025-11-11 6:23 kernel test robot
2025-11-11 7:48 ` poison_element vs highmem, was " Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: kernel test robot @ 2025-11-11 6:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: oe-lkp, lkp, Jens Axboe, Martin K. Petersen, Johannes Thumshirn,
Anuj Gupta, Kanchan Joshi, linux-block, linux-kernel, oliver.sang
Hello,
kernel test robot noticed "BUG:unable_to_handle_page_fault_for_address" on:
commit: ec7f31b2a2d3bf6b9e4d4b8cd156587f1d0607d5 ("block: make bio auto-integrity deadlock safe")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
[test failed on linux-next/master 9c0826a5d9aa4d52206dd89976858457a2a8a7ed]
in testcase: boot
config: i386-randconfig-016-20251107
compiler: clang-20
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G
(please refer to attached dmesg/kmsg for entire log/backtrace)
+------------------------------------------------+------------+------------+
| | eef09f742b | ec7f31b2a2 |
+------------------------------------------------+------------+------------+
| BUG:unable_to_handle_page_fault_for_address | 0 | 6 |
| Oops:Oops:#[##] | 0 | 6 |
| EIP:memset | 0 | 6 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 6 |
+------------------------------------------------+------------+------------+
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202511111411.9ebfa1ba-lkp@intel.com
[ 1.770141][ T1] BUG: unable to handle page fault for address: fffba000
[ 1.771287][ T1] #PF: supervisor write access in kernel mode
[ 1.772177][ T1] #PF: error_code(0x0002) - not-present page
[ 1.772326][ T1] *pde = 03171067 *pte = 00000000
[ 1.772326][ T1] Oops: Oops: 0002 [#1]
[ 1.772326][ T1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca
[ 1.772326][ T1] Tainted: [T]=RANDSTRUCT
[ 1.772326][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 1.772326][ T1] EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)
[ 1.772326][ T1] Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56
All code
========
0: a5 movsl %ds:(%rsi),%es:(%rdi)
1: 8b 4d f4 mov -0xc(%rbp),%ecx
4: 83 e1 03 and $0x3,%ecx
7: 74 02 je 0xb
9: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi)
b: 83 c4 04 add $0x4,%esp
e: 5e pop %rsi
f: 5f pop %rdi
10: 5d pop %rbp
11: 2e e9 73 41 01 00 cs jmp 0x1418a
17: 90 nop
18: 90 nop
19: 90 nop
1a: 3e 8d 74 26 00 ds lea 0x0(%rsi,%riz,1),%esi
1f: 55 push %rbp
20: 89 e5 mov %esp,%ebp
22: 57 push %rdi
23: 56 push %rsi
24: 89 c6 mov %eax,%esi
26: 89 d0 mov %edx,%eax
28: 89 f7 mov %esi,%edi
2a:* f3 aa rep stos %al,%es:(%rdi) <-- trapping instruction
2c: 89 f0 mov %esi,%eax
2e: 5e pop %rsi
2f: 5f pop %rdi
30: 5d pop %rbp
31: 2e e9 53 41 01 00 cs jmp 0x1418a
37: cc int3
38: cc int3
39: cc int3
3a: 55 push %rbp
3b: 89 e5 mov %esp,%ebp
3d: 53 push %rbx
3e: 57 push %rdi
3f: 56 push %rsi
Code starting with the faulting instruction
===========================================
0: f3 aa rep stos %al,%es:(%rdi)
2: 89 f0 mov %esi,%eax
4: 5e pop %rsi
5: 5f pop %rdi
6: 5d pop %rbp
7: 2e e9 53 41 01 00 cs jmp 0x14160
d: cc int3
e: cc int3
f: cc int3
10: 55 push %rbp
11: 89 e5 mov %esp,%ebp
13: 53 push %rbx
14: 57 push %rdi
15: 56 push %rsi
[ 1.772326][ T1] EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b
[ 1.772326][ T1] ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8
[ 1.772326][ T1] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287
[ 1.772326][ T1] CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690
[ 1.772326][ T1] Call Trace:
[ 1.772326][ T1] poison_element (mm/mempool.c:83 mm/mempool.c:102)
[ 1.772326][ T1] mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)
[ 1.772326][ T1] mempool_init_noprof (mm/mempool.c:250 (discriminator 1))
[ 1.772326][ T1] ? mempool_alloc_pages (mm/mempool.c:640)
[ 1.772326][ T1] bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))
[ 1.772326][ T1] ? mempool_alloc_pages (mm/mempool.c:640)
[ 1.772326][ T1] do_one_initcall (init/main.c:1283)
[ 1.772326][ T1] ? kvm_sched_clock_read (arch/x86/kernel/kvmclock.c:91)
[ 1.772326][ T1] ? sched_clock_noinstr (arch/x86/kernel/tsc.c:271)
[ 1.772326][ T1] ? local_clock_noinstr (kernel/sched/clock.c:272 kernel/sched/clock.c:309)
[ 1.772326][ T1] ? __lock_acquire (kernel/locking/lockdep.c:4674 kernel/locking/lockdep.c:5191)
[ 1.772326][ T1] ? kvm_sched_clock_read (arch/x86/kernel/kvmclock.c:91)
[ 1.772326][ T1] ? sched_clock_noinstr (arch/x86/kernel/tsc.c:271)
[ 1.772326][ T1] ? local_clock_noinstr (kernel/sched/clock.c:272 kernel/sched/clock.c:309)
[ 1.772326][ T1] ? local_clock (arch/x86/include/asm/preempt.h:85 (discriminator 9) kernel/sched/clock.c:319 (discriminator 9))
[ 1.772326][ T1] ? lock_release (kernel/locking/lockdep.c:353 kernel/locking/lockdep.c:5542 kernel/locking/lockdep.c:5889)
[ 1.772326][ T1] ? clockevents_program_event (kernel/time/clockevents.c:?)
[ 1.772326][ T1] ? ktime_get (include/linux/seqlock.h:391 (discriminator 3) include/linux/seqlock.h:411 (discriminator 3) kernel/time/timekeeping.c:828 (discriminator 3))
[ 1.772326][ T1] ? sched_balance_trigger (kernel/sched/fair.c:?)
[ 1.772326][ T1] ? run_posix_cpu_timers (include/linux/sched/deadline.h:15 include/linux/sched/deadline.h:24 kernel/time/posix-cpu-timers.c:1123 kernel/time/posix-cpu-timers.c:1428)
[ 1.772326][ T1] ? clockevents_program_event (kernel/time/clockevents.c:336)
[ 1.772326][ T1] ? update_process_times (kernel/time/timer.c:2481)
[ 1.772326][ T1] ? tick_handle_periodic (kernel/time/tick-common.c:120)
[ 1.772326][ T1] ? vmware_sched_clock (arch/x86/kernel/apic/apic.c:1052)
[ 1.772326][ T1] ? trace_hardirqs_on (kernel/trace/trace_preemptirq.c:80)
[ 1.772326][ T1] ? irqentry_exit (kernel/entry/common.c:224 (discriminator 32768))
[ 1.772326][ T1] ? sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052 (discriminator 6))
[ 1.772326][ T1] ? handle_exception (arch/x86/entry/entry_32.S:1055)
[ 1.772326][ T1] ? netdev_bits (lib/vsprintf.c:650 lib/vsprintf.c:695 lib/vsprintf.c:721 lib/vsprintf.c:1787)
[ 1.772326][ T1] ? strlen (arch/x86/lib/string_32.c:167)
[ 1.772326][ T1] ? next_arg (lib/cmdline.c:273)
[ 1.772326][ T1] ? parameq (kernel/params.c:90 (discriminator 1) kernel/params.c:99 (discriminator 1))
[ 1.772326][ T1] ? deadline_init (block/bio-integrity.c:482)
[ 1.772326][ T1] do_initcall_level (init/main.c:1344 (discriminator 6))
[ 1.772326][ T1] do_initcalls (init/main.c:1358 (discriminator 2))
[ 1.772326][ T1] do_basic_setup (init/main.c:1381)
[ 1.772326][ T1] kernel_init_freeable (init/main.c:1597)
[ 1.772326][ T1] ? rest_init (init/main.c:1475)
[ 1.772326][ T1] kernel_init (init/main.c:1485)
[ 1.772326][ T1] ret_from_fork (arch/x86/kernel/process.c:164)
[ 1.772326][ T1] ? rest_init (init/main.c:1475)
[ 1.772326][ T1] ret_from_fork_asm (arch/x86/entry/entry_32.S:737)
[ 1.772326][ T1] entry_INT80_32 (arch/x86/entry/entry_32.S:945)
[ 1.772326][ T1] Modules linked in:
[ 1.772326][ T1] CR2: 00000000fffba000
[ 1.772326][ T1] ---[ end trace 0000000000000000 ]---
[ 1.772326][ T1] EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)
[ 1.772326][ T1] Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56
All code
========
0: a5 movsl %ds:(%rsi),%es:(%rdi)
1: 8b 4d f4 mov -0xc(%rbp),%ecx
4: 83 e1 03 and $0x3,%ecx
7: 74 02 je 0xb
9: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi)
b: 83 c4 04 add $0x4,%esp
e: 5e pop %rsi
f: 5f pop %rdi
10: 5d pop %rbp
11: 2e e9 73 41 01 00 cs jmp 0x1418a
17: 90 nop
18: 90 nop
19: 90 nop
1a: 3e 8d 74 26 00 ds lea 0x0(%rsi,%riz,1),%esi
1f: 55 push %rbp
20: 89 e5 mov %esp,%ebp
22: 57 push %rdi
23: 56 push %rsi
24: 89 c6 mov %eax,%esi
26: 89 d0 mov %edx,%eax
28: 89 f7 mov %esi,%edi
2a:* f3 aa rep stos %al,%es:(%rdi) <-- trapping instruction
2c: 89 f0 mov %esi,%eax
2e: 5e pop %rsi
2f: 5f pop %rdi
30: 5d pop %rbp
31: 2e e9 53 41 01 00 cs jmp 0x1418a
37: cc int3
38: cc int3
39: cc int3
3a: 55 push %rbp
3b: 89 e5 mov %esp,%ebp
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20251111/202511111411.9ebfa1ba-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 6+ messages in thread* poison_element vs highmem, was Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address
2025-11-11 6:23 [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address kernel test robot
@ 2025-11-11 7:48 ` Christoph Hellwig
2025-11-12 9:33 ` Vlastimil Babka
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2025-11-11 7:48 UTC (permalink / raw)
To: kernel test robot
Cc: Vlastimil Babka, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, linux-mm, oe-lkp, lkp, Jens Axboe,
Martin K. Petersen, Johannes Thumshirn, Anuj Gupta, Kanchan Joshi,
linux-block, linux-kernel
Looks like this is due to the code in poison_element, which tries
to memset more than PAGE_SIZE for a single page. This probably
implies we are the first users of the mempool page helpers for order > 0,
or at least the first one tested by anyone on 32-bit with highmem :)
That code seems to come from
commit bdfedb76f4f5aa5e37380e3b71adee4a39f30fc6
Author: David Rientjes <rientjes@google.com>
Date: Wed Apr 15 16:14:17 2015 -0700
mm, mempool: poison elements backed by slab allocator
originally. The easiest fix would be to just skip poisoning for this
case, although that would reduce the usefulness of the poisoning.
On Tue, Nov 11, 2025 at 02:23:39PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed "BUG:unable_to_handle_page_fault_for_address" on:
>
> commit: ec7f31b2a2d3bf6b9e4d4b8cd156587f1d0607d5 ("block: make bio auto-integrity deadlock safe")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> [test failed on linux-next/master 9c0826a5d9aa4d52206dd89976858457a2a8a7ed]
>
> in testcase: boot
>
> config: i386-randconfig-016-20251107
> compiler: clang-20
> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G
> [ 1.772326][ T1] Call Trace:
> [ 1.772326][ T1] poison_element (mm/mempool.c:83 mm/mempool.c:102)
> [ 1.772326][ T1] mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)
> [ 1.772326][ T1] mempool_init_noprof (mm/mempool.c:250 (discriminator 1))
> [ 1.772326][ T1] ? mempool_alloc_pages (mm/mempool.c:640)
> [ 1.772326][ T1] bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))
> [ 1.772326][ T1] ? mempool_alloc_pages (mm/mempool.c:640)
> [ 1.772326][ T1] do_one_initcall (init/main.c:1283)
> [ 1.772326][ T1] ? kvm_sched_clock_read (arch/x86/kernel/kvmclock.c:91)
> [ 1.772326][ T1] ? sched_clock_noinstr (arch/x86/kernel/tsc.c:271)
> [ 1.772326][ T1] ? local_clock_noinstr (kernel/sched/clock.c:272 kernel/sched/clock.c:309)
> [ 1.772326][ T1] ? __lock_acquire (kernel/locking/lockdep.c:4674 kernel/locking/lockdep.c:5191)
> [ 1.772326][ T1] ? kvm_sched_clock_read (arch/x86/kernel/kvmclock.c:91)
> [ 1.772326][ T1] ? sched_clock_noinstr (arch/x86/kernel/tsc.c:271)
> [ 1.772326][ T1] ? local_clock_noinstr (kernel/sched/clock.c:272 kernel/sched/clock.c:309)
> [ 1.772326][ T1] ? local_clock (arch/x86/include/asm/preempt.h:85 (discriminator 9) kernel/sched/clock.c:319 (discriminator 9))
> [ 1.772326][ T1] ? lock_release (kernel/locking/lockdep.c:353 kernel/locking/lockdep.c:5542 kernel/locking/lockdep.c:5889)
> [ 1.772326][ T1] ? clockevents_program_event (kernel/time/clockevents.c:?)
> [ 1.772326][ T1] ? ktime_get (include/linux/seqlock.h:391 (discriminator 3) include/linux/seqlock.h:411 (discriminator 3) kernel/time/timekeeping.c:828 (discriminator 3))
> [ 1.772326][ T1] ? sched_balance_trigger (kernel/sched/fair.c:?)
> [ 1.772326][ T1] ? run_posix_cpu_timers (include/linux/sched/deadline.h:15 include/linux/sched/deadline.h:24 kernel/time/posix-cpu-timers.c:1123 kernel/time/posix-cpu-timers.c:1428)
> [ 1.772326][ T1] ? clockevents_program_event (kernel/time/clockevents.c:336)
> [ 1.772326][ T1] ? update_process_times (kernel/time/timer.c:2481)
> [ 1.772326][ T1] ? tick_handle_periodic (kernel/time/tick-common.c:120)
> [ 1.772326][ T1] ? vmware_sched_clock (arch/x86/kernel/apic/apic.c:1052)
> [ 1.772326][ T1] ? trace_hardirqs_on (kernel/trace/trace_preemptirq.c:80)
> [ 1.772326][ T1] ? irqentry_exit (kernel/entry/common.c:224 (discriminator 32768))
> [ 1.772326][ T1] ? sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052 (discriminator 6))
> [ 1.772326][ T1] ? handle_exception (arch/x86/entry/entry_32.S:1055)
> [ 1.772326][ T1] ? netdev_bits (lib/vsprintf.c:650 lib/vsprintf.c:695 lib/vsprintf.c:721 lib/vsprintf.c:1787)
> [ 1.772326][ T1] ? strlen (arch/x86/lib/string_32.c:167)
> [ 1.772326][ T1] ? next_arg (lib/cmdline.c:273)
> [ 1.772326][ T1] ? parameq (kernel/params.c:90 (discriminator 1) kernel/params.c:99 (discriminator 1))
> [ 1.772326][ T1] ? deadline_init (block/bio-integrity.c:482)
> [ 1.772326][ T1] do_initcall_level (init/main.c:1344 (discriminator 6))
> [ 1.772326][ T1] do_initcalls (init/main.c:1358 (discriminator 2))
> [ 1.772326][ T1] do_basic_setup (init/main.c:1381)
> [ 1.772326][ T1] kernel_init_freeable (init/main.c:1597)
> [ 1.772326][ T1] ? rest_init (init/main.c:1475)
> [ 1.772326][ T1] kernel_init (init/main.c:1485)
> [ 1.772326][ T1] ret_from_fork (arch/x86/kernel/process.c:164)
> [ 1.772326][ T1] ? rest_init (init/main.c:1475)
> [ 1.772326][ T1] ret_from_fork_asm (arch/x86/entry/entry_32.S:737)
> [ 1.772326][ T1] entry_INT80_32 (arch/x86/entry/entry_32.S:945)
> [ 1.772326][ T1] Modules linked in:
> [ 1.772326][ T1] CR2: 00000000fffba000
> [ 1.772326][ T1] ---[ end trace 0000000000000000 ]---
> [ 1.772326][ T1] EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)
> [ 1.772326][ T1] Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56
> All code
> ========
> 0: a5 movsl %ds:(%rsi),%es:(%rdi)
> 1: 8b 4d f4 mov -0xc(%rbp),%ecx
> 4: 83 e1 03 and $0x3,%ecx
> 7: 74 02 je 0xb
> 9: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi)
> b: 83 c4 04 add $0x4,%esp
> e: 5e pop %rsi
> f: 5f pop %rdi
> 10: 5d pop %rbp
> 11: 2e e9 73 41 01 00 cs jmp 0x1418a
> 17: 90 nop
> 18: 90 nop
> 19: 90 nop
> 1a: 3e 8d 74 26 00 ds lea 0x0(%rsi,%riz,1),%esi
> 1f: 55 push %rbp
> 20: 89 e5 mov %esp,%ebp
> 22: 57 push %rdi
> 23: 56 push %rsi
> 24: 89 c6 mov %eax,%esi
> 26: 89 d0 mov %edx,%eax
> 28: 89 f7 mov %esi,%edi
> 2a:* f3 aa rep stos %al,%es:(%rdi) <-- trapping instruction
> 2c: 89 f0 mov %esi,%eax
> 2e: 5e pop %rsi
> 2f: 5f pop %rdi
> 30: 5d pop %rbp
> 31: 2e e9 53 41 01 00 cs jmp 0x1418a
> 37: cc int3
> 38: cc int3
> 39: cc int3
> 3a: 55 push %rbp
> 3b: 89 e5 mov %esp,%ebp
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20251111/202511111411.9ebfa1ba-lkp@intel.com
>
>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
---end quoted text---
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: poison_element vs highmem, was Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address
2025-11-11 7:48 ` poison_element vs highmem, was " Christoph Hellwig
@ 2025-11-12 9:33 ` Vlastimil Babka
2025-11-13 7:44 ` Oliver Sang
0 siblings, 1 reply; 6+ messages in thread
From: Vlastimil Babka @ 2025-11-12 9:33 UTC (permalink / raw)
To: Christoph Hellwig, kernel test robot
Cc: Andrew Morton, Christoph Lameter, David Rientjes, Roman Gushchin,
Harry Yoo, linux-mm, oe-lkp, lkp, Jens Axboe, Martin K. Petersen,
Johannes Thumshirn, Anuj Gupta, Kanchan Joshi, linux-block,
linux-kernel
On 11/11/25 08:48, Christoph Hellwig wrote:
> Looks like this is due to the code in poison_element, which tries
> to memset more than PAGE_SIZE for a single page. This probably
> implies we are the first users of the mempool page helpers for order > 0,
> or at least the first one tested by anyone on 32-bit with highmem :)
>
> That code seems to come from
>
> commit bdfedb76f4f5aa5e37380e3b71adee4a39f30fc6
> Author: David Rientjes <rientjes@google.com>
> Date: Wed Apr 15 16:14:17 2015 -0700
>
> mm, mempool: poison elements backed by slab allocator
>
> originally. The easiest fix would be to just skip poisoning for this
> case, although that would reduce the usefulness of the poisoning.
#syz test
----8<----
From 4d97b55c208c611cb01062e0fbf9dbda9f5617d5 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Wed, 12 Nov 2025 10:29:52 +0100
Subject: [PATCH] mm/mempool: fix poisoning order>0 pages with HIGHMEM
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/mempool.c | 28 ++++++++++++++++++++++------
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/mm/mempool.c b/mm/mempool.c
index 1c38e873e546..75fea9441b93 100644
--- a/mm/mempool.c
+++ b/mm/mempool.c
@@ -68,10 +68,18 @@ static void check_element(mempool_t *pool, void *element)
} else if (pool->free == mempool_free_pages) {
/* Mempools backed by page allocator */
int order = (int)(long)pool->pool_data;
- void *addr = kmap_local_page((struct page *)element);
+#ifdef CONFIG_HIGHMEM
+ for (int i = 0; i < (1 << order); i++) {
+ struct page *page = (struct page *)element;
+ void *addr = kmap_local_page(page + i);
- __check_element(pool, addr, 1UL << (PAGE_SHIFT + order));
- kunmap_local(addr);
+ __check_element(pool, addr, PAGE_SIZE);
+ kunmap_local(addr);
+ }
+#else
+ void *addr = page_address((struct page *)element);
+ __check_element(pool, addr, PAGE_SIZE << order);
+#endif
}
}
@@ -97,10 +105,18 @@ static void poison_element(mempool_t *pool, void *element)
} else if (pool->alloc == mempool_alloc_pages) {
/* Mempools backed by page allocator */
int order = (int)(long)pool->pool_data;
- void *addr = kmap_local_page((struct page *)element);
+#ifdef CONFIG_HIGHMEM
+ for (int i = 0; i < (1 << order); i++) {
+ struct page *page = (struct page *)element;
+ void *addr = kmap_local_page(page + i);
- __poison_element(addr, 1UL << (PAGE_SHIFT + order));
- kunmap_local(addr);
+ __poison_element(addr, PAGE_SIZE);
+ kunmap_local(addr);
+ }
+#else
+ void *addr = page_address((struct page *)element);
+ __poison_element(addr, PAGE_SIZE << order);
+#endif
}
}
#else /* CONFIG_SLUB_DEBUG_ON */
--
2.51.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: poison_element vs highmem, was Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address
2025-11-12 9:33 ` Vlastimil Babka
@ 2025-11-13 7:44 ` Oliver Sang
2025-11-13 13:48 ` Vlastimil Babka
0 siblings, 1 reply; 6+ messages in thread
From: Oliver Sang @ 2025-11-13 7:44 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Christoph Hellwig, Andrew Morton, Christoph Lameter,
David Rientjes, Roman Gushchin, Harry Yoo, linux-mm, oe-lkp, lkp,
Jens Axboe, Martin K. Petersen, Johannes Thumshirn, Anuj Gupta,
Kanchan Joshi, linux-block, linux-kernel, oliver.sang
hi, Vlastimil Babka,
On Wed, Nov 12, 2025 at 10:33:32AM +0100, Vlastimil Babka wrote:
> On 11/11/25 08:48, Christoph Hellwig wrote:
> > Looks like this is due to the code in poison_element, which tries
> > to memset more than PAGE_SIZE for a single page. This probably
> > implies we are the first users of the mempool page helpers for order > 0,
> > or at least the first one tested by anyone on 32-bit with highmem :)
> >
> > That code seems to come from
> >
> > commit bdfedb76f4f5aa5e37380e3b71adee4a39f30fc6
> > Author: David Rientjes <rientjes@google.com>
> > Date: Wed Apr 15 16:14:17 2015 -0700
> >
> > mm, mempool: poison elements backed by slab allocator
> >
> > originally. The easiest fix would be to just skip poisoning for this
> > case, although that would reduce the usefulness of the poisoning.
>
> #syz test
we applied below patch upon ec7f31b2a2 directly, and confirmed the issue we
reported gone now with the patch.
Tested-by: kernel test robot <oliver.sang@intel.com>
BTW, we are kernel test robot, not the syzbot :) thanks
>
> ----8<----
> From 4d97b55c208c611cb01062e0fbf9dbda9f5617d5 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Wed, 12 Nov 2025 10:29:52 +0100
> Subject: [PATCH] mm/mempool: fix poisoning order>0 pages with HIGHMEM
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/mempool.c | 28 ++++++++++++++++++++++------
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/mm/mempool.c b/mm/mempool.c
> index 1c38e873e546..75fea9441b93 100644
> --- a/mm/mempool.c
> +++ b/mm/mempool.c
> @@ -68,10 +68,18 @@ static void check_element(mempool_t *pool, void *element)
> } else if (pool->free == mempool_free_pages) {
> /* Mempools backed by page allocator */
> int order = (int)(long)pool->pool_data;
> - void *addr = kmap_local_page((struct page *)element);
> +#ifdef CONFIG_HIGHMEM
> + for (int i = 0; i < (1 << order); i++) {
> + struct page *page = (struct page *)element;
> + void *addr = kmap_local_page(page + i);
>
> - __check_element(pool, addr, 1UL << (PAGE_SHIFT + order));
> - kunmap_local(addr);
> + __check_element(pool, addr, PAGE_SIZE);
> + kunmap_local(addr);
> + }
> +#else
> + void *addr = page_address((struct page *)element);
> + __check_element(pool, addr, PAGE_SIZE << order);
> +#endif
> }
> }
>
> @@ -97,10 +105,18 @@ static void poison_element(mempool_t *pool, void *element)
> } else if (pool->alloc == mempool_alloc_pages) {
> /* Mempools backed by page allocator */
> int order = (int)(long)pool->pool_data;
> - void *addr = kmap_local_page((struct page *)element);
> +#ifdef CONFIG_HIGHMEM
> + for (int i = 0; i < (1 << order); i++) {
> + struct page *page = (struct page *)element;
> + void *addr = kmap_local_page(page + i);
>
> - __poison_element(addr, 1UL << (PAGE_SHIFT + order));
> - kunmap_local(addr);
> + __poison_element(addr, PAGE_SIZE);
> + kunmap_local(addr);
> + }
> +#else
> + void *addr = page_address((struct page *)element);
> + __poison_element(addr, PAGE_SIZE << order);
> +#endif
> }
> }
> #else /* CONFIG_SLUB_DEBUG_ON */
> --
> 2.51.1
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: poison_element vs highmem, was Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address
2025-11-13 7:44 ` Oliver Sang
@ 2025-11-13 13:48 ` Vlastimil Babka
2025-11-13 14:48 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Vlastimil Babka @ 2025-11-13 13:48 UTC (permalink / raw)
To: Oliver Sang
Cc: Christoph Hellwig, Andrew Morton, Christoph Lameter,
David Rientjes, Roman Gushchin, Harry Yoo, linux-mm, oe-lkp, lkp,
Jens Axboe, Martin K. Petersen, Johannes Thumshirn, Anuj Gupta,
Kanchan Joshi, linux-block, linux-kernel
On 11/13/25 08:44, Oliver Sang wrote:
> hi, Vlastimil Babka,
>
> On Wed, Nov 12, 2025 at 10:33:32AM +0100, Vlastimil Babka wrote:
>> On 11/11/25 08:48, Christoph Hellwig wrote:
>> > Looks like this is due to the code in poison_element, which tries
>> > to memset more than PAGE_SIZE for a single page. This probably
>> > implies we are the first users of the mempool page helpers for order > 0,
>> > or at least the first one tested by anyone on 32-bit with highmem :)
>> >
>> > That code seems to come from
>> >
>> > commit bdfedb76f4f5aa5e37380e3b71adee4a39f30fc6
>> > Author: David Rientjes <rientjes@google.com>
>> > Date: Wed Apr 15 16:14:17 2015 -0700
>> >
>> > mm, mempool: poison elements backed by slab allocator
>> >
>> > originally. The easiest fix would be to just skip poisoning for this
>> > case, although that would reduce the usefulness of the poisoning.
>>
>> #syz test
>
> we applied below patch upon ec7f31b2a2 directly, and confirmed the issue we
> reported gone now with the patch.
>
> Tested-by: kernel test robot <oliver.sang@intel.com>
Thanks!
> BTW, we are kernel test robot, not the syzbot :) thanks
Yeah I realized only after sending...
I'll make this a full patch then. How urgent is it, Christoph? I suppose
this is related to the bulk mempool changes, and we discussed the users will
target 6.20 (7.0?) merge window? So landing this fix in 6.19 is enough?
>> ----8<----
>> From 4d97b55c208c611cb01062e0fbf9dbda9f5617d5 Mon Sep 17 00:00:00 2001
>> From: Vlastimil Babka <vbabka@suse.cz>
>> Date: Wed, 12 Nov 2025 10:29:52 +0100
>> Subject: [PATCH] mm/mempool: fix poisoning order>0 pages with HIGHMEM
>>
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>> ---
>> mm/mempool.c | 28 ++++++++++++++++++++++------
>> 1 file changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/mm/mempool.c b/mm/mempool.c
>> index 1c38e873e546..75fea9441b93 100644
>> --- a/mm/mempool.c
>> +++ b/mm/mempool.c
>> @@ -68,10 +68,18 @@ static void check_element(mempool_t *pool, void *element)
>> } else if (pool->free == mempool_free_pages) {
>> /* Mempools backed by page allocator */
>> int order = (int)(long)pool->pool_data;
>> - void *addr = kmap_local_page((struct page *)element);
>> +#ifdef CONFIG_HIGHMEM
>> + for (int i = 0; i < (1 << order); i++) {
>> + struct page *page = (struct page *)element;
>> + void *addr = kmap_local_page(page + i);
>>
>> - __check_element(pool, addr, 1UL << (PAGE_SHIFT + order));
>> - kunmap_local(addr);
>> + __check_element(pool, addr, PAGE_SIZE);
>> + kunmap_local(addr);
>> + }
>> +#else
>> + void *addr = page_address((struct page *)element);
>> + __check_element(pool, addr, PAGE_SIZE << order);
>> +#endif
>> }
>> }
>>
>> @@ -97,10 +105,18 @@ static void poison_element(mempool_t *pool, void *element)
>> } else if (pool->alloc == mempool_alloc_pages) {
>> /* Mempools backed by page allocator */
>> int order = (int)(long)pool->pool_data;
>> - void *addr = kmap_local_page((struct page *)element);
>> +#ifdef CONFIG_HIGHMEM
>> + for (int i = 0; i < (1 << order); i++) {
>> + struct page *page = (struct page *)element;
>> + void *addr = kmap_local_page(page + i);
>>
>> - __poison_element(addr, 1UL << (PAGE_SHIFT + order));
>> - kunmap_local(addr);
>> + __poison_element(addr, PAGE_SIZE);
>> + kunmap_local(addr);
>> + }
>> +#else
>> + void *addr = page_address((struct page *)element);
>> + __poison_element(addr, PAGE_SIZE << order);
>> +#endif
>> }
>> }
>> #else /* CONFIG_SLUB_DEBUG_ON */
>> --
>> 2.51.1
>>
>>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: poison_element vs highmem, was Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address
2025-11-13 13:48 ` Vlastimil Babka
@ 2025-11-13 14:48 ` Christoph Hellwig
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2025-11-13 14:48 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Oliver Sang, Christoph Hellwig, Andrew Morton, Christoph Lameter,
David Rientjes, Roman Gushchin, Harry Yoo, linux-mm, oe-lkp, lkp,
Jens Axboe, Martin K. Petersen, Johannes Thumshirn, Anuj Gupta,
Kanchan Joshi, linux-block, linux-kernel
On Thu, Nov 13, 2025 at 02:48:06PM +0100, Vlastimil Babka wrote:
> I'll make this a full patch then. How urgent is it, Christoph? I suppose
> this is related to the bulk mempool changes, and we discussed the users will
> target 6.20 (7.0?) merge window? So landing this fix in 6.19 is enough?
The trigger is a change in the block tree that is in linux-next. So 6.19
should be fine, although getting it into linux-next ASAP would be great.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-11-13 14:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-11 6:23 [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address kernel test robot
2025-11-11 7:48 ` poison_element vs highmem, was " Christoph Hellwig
2025-11-12 9:33 ` Vlastimil Babka
2025-11-13 7:44 ` Oliver Sang
2025-11-13 13:48 ` Vlastimil Babka
2025-11-13 14:48 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox