Re: [PATCH 4.4 00/37] 4.4.110-stable review

[Greg Kroah-Hartman]

On Thu, Jan 04, 2018 at 06:14:15PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 04, 2018 at 06:11:02PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 04, 2018 at 06:03:15PM +0100, Willy Tarreau wrote:
> > > On Thu, Jan 04, 2018 at 05:53:06PM +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Jan 04, 2018 at 11:38:25AM -0500, Pavel Tatashin wrote:
> > > > > I am getting the following panic when trying to boot 4.4.110rc1 on
> > > > > Intel(R) Xeon(R) CPU E5-2630:
> > > > > 
> > > > > [    5.923489] BUG: unable to handle kernel NULL pointer dereference
> > > > > at 000000000000000d
> > > > > [    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
> > > > > [    5.940142] PGD 0
> > > > > [    5.942400] Oops: 0002 [#1] SMP
> > > > > [    5.946023] Modules linked in:
> > > > > [    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
> > > > > 4.4.110-rc1_pt_linux-4.4.110rc1 #1
> > > > > [    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
> > > > > X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
> > > > > [    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
> > > > > ffff881ff2f24000
> > > > > [    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
> > > > > dyntick_save_progress_counter+0x12/0x50
> > > > > [    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
> > > > > [    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
> > > > > [    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
> > > > > [    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
> > > > > [    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
> > > > > [    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
> > > > > [    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
> > > > > knlGS:0000000000000000
> > > > > [    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > > [    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
> > > > > [    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > > [    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > > > [    6.073603] Stack:
> > > > > [    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
> > > > > ffff881ff2f27e60
> > > > > [    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
> > > > > ffffffff81b127a0
> > > > > [    6.092465]  0000000000000001 0000000000000000 0000000000000003
> > > > > ffff881ff2f27eb8
> > > > > [    6.100768] Call Trace:
> > > > > [    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
> > > > > [    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
> > > > > [    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
> > > > > [    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
> > > > > [    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
> > > > > [    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
> > > > > [    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
> > > > > [    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
> > > > > [    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
> > > > > 
> > > > > I tried to bisect the problem, but when I try to boot only with:
> > > > > "KAISER: Kernel Address Isolation" machine hangs during boot and
> > > > > reboots without any panic message.
> > > > > 
> > > > > 4.4.109 boots fine
> > > > > 4.9.75rc1 also boots fine.
> > > > 
> > > > Hm, so I'm guessing 4.15-rc6 also works?
> > > > 
> > > > Odd that 4.9.75-rc1 fails.
> > > 
> > > s/4.9.75/4.4.110/ I suppose.
> > 
> > Yes, mistake on my side.
> > 
> > > Can't this be because more patches are required in 4.4 to support this
> > > patch set ? Or maybe a manual fix for a conflict that went wrong ? Just
> > > trying to guess.
> > 
> > Odd thing is, the 4.9 series started from the 4.4 code for most of the
> > patches, so I would expect that one to fail...
> 
> Also, the 4.4 patches were supposed to have been better tested, I need
> to go dig and see what I messed up here...

Nope, it matches up with what is in SLES12 exactly, I must be missing
something else here as a prerequisite...