Re: Init panic in 4.4 PTI backports with CONFIG_PARAVIRT_CLOCK=y

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 05, 2018 at 12:55:54PM +0000, Jamie Iles wrote:
> Hi Greg,
> 
> Another panic in the 4.4 PTI backports with CONFIG_PARAVIRT_CLOCK=y:
> 
> [   83.008457] init[1]: segfault at ffffffffff5ff0c0 ip 00007ffdcbf609c5 sp 00007ffdcbeb2fa0 error 5
> [   83.012895] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [   83.012895]
> [   83.013764] CPU: 3 PID: 1 Comm: init Not tainted 4.4.110-rc1+ #84
> [   83.014345] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
> [   83.015219]  ffff880119207b68 ffff8801191579b8 ffffffff8159b31d ffffffff820441c0
> [   83.015981]  ffff880119157a90 ffff880119157a80 ffffffff8120cc1a 0000000041b58ab3
> [   83.016724]  ffffffff825a770d ffffffff8120cae0 ffff8801191487b8 0000000000000010
> [   83.017464] Call Trace:
> [   83.017708]  [<ffffffff8159b31d>] dump_stack+0x86/0xc9
> [   83.018197]  [<ffffffff8120cc1a>] panic+0x13a/0x283
> [   83.018695]  [<ffffffff8120cae0>] ? set_ti_thread_flag+0xf/0xf
> [   83.019259]  [<ffffffff81109a52>] ? mark_held_locks+0x22/0xb0
> [   83.019802]  [<ffffffff81e6bfec>] ? _raw_write_unlock_irq+0x2c/0x40
> [   83.020391]  [<ffffffff810964ef>] do_exit+0x96f/0x1480
> [   83.020885]  [<ffffffff81095b80>] ? release_task+0x8e0/0x8e0
> [   83.021437]  [<ffffffff81109d48>] ? trace_hardirqs_on_caller+0x268/0x2a0
> [   83.022089]  [<ffffffff8109932a>] do_group_exit+0xda/0x160
> [   83.022607]  [<ffffffff810ad7b3>] get_signal+0xa93/0xba0
> [   83.023132]  [<ffffffff81109a52>] ? mark_held_locks+0x22/0xb0
> [   83.023684]  [<ffffffff81007e31>] do_signal+0x91/0xab0
> [   83.024171]  [<ffffffff8107abaf>] ? force_sig_info_fault.constprop.19+0xef/0x120
> [   83.024887]  [<ffffffff81007da0>] ? setup_sigcontext+0x270/0x270
> [   83.025450]  [<ffffffff8107aac0>] ? is_prefetch.isra.16+0x260/0x260
> [   83.026041]  [<ffffffff8120d3c2>] ? printk+0x99/0xb5
> [   83.026520]  [<ffffffff8120d329>] ? power_down+0xa9/0xa9
> [   83.027057]  [<ffffffff811027df>] ? up_read+0x1f/0x40
> [   83.027559]  [<ffffffff8120d3c2>] ? printk+0x99/0xb5
> [   83.028030]  [<ffffffff8107bb55>] ? __bad_area_nosemaphore+0x265/0x2a0
> [   83.028647]  [<ffffffff81109a52>] ? mark_held_locks+0x22/0xb0
> [   83.029199]  [<ffffffff810023a2>] ? exit_to_usermode_loop+0x52/0xd0
> [   83.029789]  [<ffffffff810023c3>] exit_to_usermode_loop+0x73/0xd0
> [   83.030365]  [<ffffffff81003840>] prepare_exit_to_usermode+0x60/0x80
> [   83.031067]  [<ffffffff81e6cfc8>] retint_user+0x8/0x3c
> [   83.031699] Kernel Offset: disabled
> [   83.032067] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [   83.032067]
> 
> This one is from the PVCLOCK_FIXMAP_BEGIN fixmap page, and I can fix it 
> by additionally picking:
> 
>   6b078f5de7fc (x86, vdso, pvclock: Simplify and speed up the vdso 
>   pvclock reader)
>   dac16fba6fc5 (x86/vdso: Get pvclock data from the vvar VMA instead of 
>   the fixmap)
> 
> onto the stable-rc linux-4.4.y branch.

Nice!  That might explain a bunch of this as to why SLES12 works, but
this tree doesn't, as those patches are in SLES12.  Along with a ton of
other ones, digging through 20k of patches is "fun"...

I'll go queue them up now.

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]