* poison_element vs highmem, was Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address [not found] <202511111411.9ebfa1ba-lkp@intel.com> @ 2025-11-11 7:48 ` Christoph Hellwig 2025-11-12 9:33 ` Vlastimil Babka 0 siblings, 1 reply; 5+ 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] 5+ 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 Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address Christoph Hellwig @ 2025-11-12 9:33 ` Vlastimil Babka 2025-11-13 7:44 ` Oliver Sang 0 siblings, 1 reply; 5+ 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 [flat|nested] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2025-11-13 14:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <202511111411.9ebfa1ba-lkp@intel.com>
2025-11-11 7:48 ` poison_element vs highmem, was Re: [linux-next:master] [block] ec7f31b2a2: BUG:unable_to_handle_page_fault_for_address 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