Greeting,
FYI, we noticed BUG:unable_to_handle_page_fault_for_address due to commit (built with gcc-11):
commit: 9fd429c28073fa40f5465cd6e4769a0af80bf398 ("x86/kasan: Map shadow for percpu pages on demand")
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git x86/mm
[test failed on linux-next/master f8f60f322f0640c8edda2942ca5f84b7a27c417a]
on test machine: 128 threads 2 sockets Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz (Ice Lake) with 128G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
[ 158.064712][ T8416] BUG: unable to handle page fault for address: fffffbc00012de04
[ 158.074534][ T8416] #PF: supervisor read access in kernel mode
[ 158.074537][ T8416] #PF: error_code(0x0000) - not-present page
[ 158.095763][ T8416] PGD 207e210067 P4D 1fef217067 PUD 1fef216067 PMD 103344b067 PTE 0
[ 158.095770][ T8416] Oops: 0000 [#1] SMP KASAN NOPTI
[ 158.095773][ T8416] CPU: 34 PID: 8416 Comm: umip_test_basic Not tainted 6.1.0-rc2-00001-g9fd429c28073 #1
[ 158.107429][ T8416] RIP: 0010:get_desc (arch/x86/lib/insn-eval.c:660)
[ 158.107435][ T8416] Code: b7 02 00 00 83 e0 07 38 c2 0f 9e c1 84 d2 0f 95 c0 84 c1 0f 85 a2 02 00 00 48 ba 00 00 00 00 00 fc ff df 48 89 d8 48 c1 e8 03 <0f> b6 0c 10 48 8d 43 07 48 89 c6 48 c1 ee 03 0f b6 14 16 48 89 de
All code
========
0: b7 02 mov $0x2,%bh
2: 00 00 add %al,(%rax)
4: 83 e0 07 and $0x7,%eax
7: 38 c2 cmp %al,%dl
9: 0f 9e c1 setle %cl
c: 84 d2 test %dl,%dl
e: 0f 95 c0 setne %al
11: 84 c1 test %al,%cl
13: 0f 85 a2 02 00 00 jne 0x2bb
19: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx
20: fc ff df
23: 48 89 d8 mov %rbx,%rax
26: 48 c1 e8 03 shr $0x3,%rax
2a:* 0f b6 0c 10 movzbl (%rax,%rdx,1),%ecx <-- trapping instruction
2e: 48 8d 43 07 lea 0x7(%rbx),%rax
32: 48 89 c6 mov %rax,%rsi
35: 48 c1 ee 03 shr $0x3,%rsi
39: 0f b6 14 16 movzbl (%rsi,%rdx,1),%edx
3d: 48 89 de mov %rbx,%rsi
Code starting with the faulting instruction
===========================================
0: 0f b6 0c 10 movzbl (%rax,%rdx,1),%ecx
4: 48 8d 43 07 lea 0x7(%rbx),%rax
8: 48 89 c6 mov %rax,%rsi
b: 48 c1 ee 03 shr $0x3,%rsi
f: 0f b6 14 16 movzbl (%rsi,%rdx,1),%edx
13: 48 89 de mov %rbx,%rsi
[ 158.107438][ T8416] RSP: 0000:ffa0000031fb7c20 EFLAGS: 00010a02
[ 158.107440][ T8416] RAX: 1fffffc00012de04 RBX: fffffe000096f020 RCX: 0000000000000001
[ 158.107442][ T8416] RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffa0000031fb7ce0
[ 158.107443][ T8416] RBP: 1ff40000063f6f98 R08: 0000000000000000 R09: 0000000000000000
[ 158.107444][ T8416] R10: 0000000000000000 R11: 0000000000000000 R12: ffa0000031fb7ce0
[ 158.107446][ T8416] R13: 1ff40000063f6f85 R14: 0000000000000000 R15: 0000000000000000
[ 158.107447][ T8416] FS: 0000000000000000(0000) GS:ff11001fed300000(0063) knlGS:00000000f7eeb340
[ 158.107449][ T8416] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 158.107450][ T8416] CR2: fffffbc00012de04 CR3: 000000109c3d0006 CR4: 0000000000771ee0
[ 158.107452][ T8416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 158.107453][ T8416] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 158.107454][ T8416] PKRU: 55555554
[ 158.107455][ T8416] Call Trace:
[ 158.107456][ T8416] <TASK>
[ 158.107457][ T8416] ? get_segment_selector (arch/x86/lib/insn-eval.c:622)
[ 158.107460][ T8416] ? __mod_lruvec_page_state (arch/x86/include/asm/preempt.h:85 include/linux/rcupdate.h:99 include/linux/rcupdate.h:770 mm/memcontrol.c:843)
[ 158.107465][ T8416] insn_get_seg_base (arch/x86/lib/insn-eval.c:725)
[ 158.107467][ T8416] ? do_read_fault (mm/memory.c:4523 mm/memory.c:4549)
[ 158.107471][ T8416] ? pt_regs_offset (arch/x86/lib/insn-eval.c:682)
[ 158.107473][ T8416] ? _raw_spin_lock_irq (arch/x86/include/asm/atomic.h:202 include/linux/atomic/atomic-instrumented.h:543 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:186 include/linux/spinlock_api_smp.h:120 kernel/locking/spinlock.c:170)
[ 158.107478][ T8416] ? _raw_spin_lock_bh (kernel/locking/spinlock.c:169)
[ 158.109757][ T1590]
[ 158.117492][ T8416] insn_fetch_from_user (arch/x86/lib/insn-eval.c:1476 arch/x86/lib/insn-eval.c:1505)
[ 158.117496][ T8416] fixup_umip_exception (arch/x86/kernel/umip.c:353)
[ 158.131844][ T8416] ? emulate_umip_insn (arch/x86/kernel/umip.c:337)
[ 158.146371][ T8416] ? __ia32_sys_pidfd_send_signal (kernel/signal.c:4088)
[ 158.146376][ T8416] ? __might_fault (mm/memory.c:5648)
[ 158.171730][ T8416] ? __ia32_compat_sys_rt_sigaction (kernel/signal.c:4464 kernel/signal.c:4435 kernel/signal.c:4435)
[ 158.171733][ T8416] ? __ia32_sys_rt_sigaction (kernel/signal.c:4435)
[ 158.187382][ T8416] exc_general_protection (arch/x86/kernel/traps.c:733 arch/x86/kernel/traps.c:721)
[ 158.187386][ T8416] asm_exc_general_protection (arch/x86/include/asm/idtentry.h:564)
[ 158.203024][ T8416] RIP: 0023:0x8049aaf
[ 158.203026][ T8416] Code: 55 ee 8b 45 dc 01 d0 c6 00 00 83 45 dc 01 83 7d dc 05 7e eb 83 ec 08 8d 45 ee 50 8d 83 44 d6 ff ff 50 e8 54 f6 ff ff 83 c4 10 <0f> 01 45 ee 90 90 90 90 90 90 90 90 90 90 90 90 90 90 83 ec 08 6a
All code
========
0: 55 push %rbp
1: ee out %al,(%dx)
2: 8b 45 dc mov -0x24(%rbp),%eax
5: 01 d0 add %edx,%eax
7: c6 00 00 movb $0x0,(%rax)
a: 83 45 dc 01 addl $0x1,-0x24(%rbp)
e: 83 7d dc 05 cmpl $0x5,-0x24(%rbp)
12: 7e eb jle 0xffffffffffffffff
14: 83 ec 08 sub $0x8,%esp
17: 8d 45 ee lea -0x12(%rbp),%eax
1a: 50 push %rax
1b: 8d 83 44 d6 ff ff lea -0x29bc(%rbx),%eax
21: 50 push %rax
22: e8 54 f6 ff ff callq 0xfffffffffffff67b
27: 83 c4 10 add $0x10,%esp
2a:* 0f 01 45 ee sgdt -0x12(%rbp) <-- trapping instruction
2e: 90 nop
2f: 90 nop
30: 90 nop
31: 90 nop
32: 90 nop
33: 90 nop
34: 90 nop
35: 90 nop
36: 90 nop
37: 90 nop
38: 90 nop
39: 90 nop
3a: 90 nop
3b: 90 nop
3c: 83 ec 08 sub $0x8,%esp
3f: 6a .byte 0x6a
Code starting with the faulting instruction
===========================================
0: 0f 01 45 ee sgdt -0x12(%rbp)
4: 90 nop
5: 90 nop
6: 90 nop
7: 90 nop
8: 90 nop
9: 90 nop
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
10: 90 nop
11: 90 nop
12: 83 ec 08 sub $0x8,%esp
15: 6a .byte 0x6a
We are sorry that the testcase and reproducing steps are not available
for this case. Hope the call trace can help to investigate, and we can
also help to do further verification if needed. Thanks.
If you fix the issue, kindly add following tag
| Reported-by: kernel test robot <[email protected]>
| Link: https://lore.kernel.org/oe-lkp/[email protected]
--
0-DAY CI Kernel Test Service
https://01.org/lkp
On Sat, Nov 12, 2022, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed BUG:unable_to_handle_page_fault_for_address due to commit (built with gcc-11):
>
> commit: 9fd429c28073fa40f5465cd6e4769a0af80bf398 ("x86/kasan: Map shadow for percpu pages on demand")
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git x86/mm
>
> [test failed on linux-next/master f8f60f322f0640c8edda2942ca5f84b7a27c417a]
>
> on test machine: 128 threads 2 sockets Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz (Ice Lake) with 128G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> [ 158.064712][ T8416] BUG: unable to handle page fault for address: fffffbc00012de04
> [ 158.074534][ T8416] #PF: supervisor read access in kernel mode
> [ 158.074537][ T8416] #PF: error_code(0x0000) - not-present page
> [ 158.095763][ T8416] PGD 207e210067 P4D 1fef217067 PUD 1fef216067 PMD 103344b067 PTE 0
> [ 158.095770][ T8416] Oops: 0000 [#1] SMP KASAN NOPTI
> [ 158.095773][ T8416] CPU: 34 PID: 8416 Comm: umip_test_basic Not tainted 6.1.0-rc2-00001-g9fd429c28073 #1
> [ 158.107429][ T8416] RIP: 0010:get_desc (arch/x86/lib/insn-eval.c:660)
> [ 158.107465][ T8416] insn_get_seg_base (arch/x86/lib/insn-eval.c:725)
> [ 158.117492][ T8416] insn_fetch_from_user (arch/x86/lib/insn-eval.c:1476 arch/x86/lib/insn-eval.c:1505)
> [ 158.117496][ T8416] fixup_umip_exception (arch/x86/kernel/umip.c:353)
> [ 158.187382][ T8416] exc_general_protection (arch/x86/kernel/traps.c:733 arch/x86/kernel/traps.c:721)
> [ 158.187386][ T8416] asm_exc_general_protection (arch/x86/include/asm/idtentry.h:564)
...
> We are sorry that the testcase and reproducing steps are not available
> for this case. Hope the call trace can help to investigate, and we can
> also help to do further verification if needed. Thanks.
Luckily, it's a known issue.
https://lore.kernel.org/all/[email protected]