On 11/01/2019 09:46, Greg KH wrote: > On Fri, Jan 11, 2019 at 08:59:52AM +0100, Juergen Gross wrote: >> On 22/12/2018 12:14, Juergen Gross wrote: >>> On 06/12/2018 12:46, Greg KH wrote: >>>> On Thu, Dec 06, 2018 at 12:31:15PM +0100, Juergen Gross wrote: >>>>> On 06/12/2018 12:13, Greg KH wrote: >>>>>> On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote: >>>>>>> On 29/11/2018 14:26, Kirill A. Shutemov wrote: >>>>>>>> On Thu, Nov 29, 2018 at 09:41:25AM +0000, Juergen Gross wrote: >>>>>>>>> On 29/11/2018 02:22, Hans van Kranenburg wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> As also seen at: >>>>>>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951 >>>>>>>>>> >>>>>>>>>> Attached there are two serial console output logs. One is starting with >>>>>>>>>> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen. >>>>>>>>>> >>>>>>>>>> [ 2.085543] BUG: unable to handle kernel paging request at >>>>>>>>>> ffff888d9fffc000 >>>>>>>>>> [ 2.085610] PGD 200c067 P4D 200c067 PUD 0 >>>>>>>>>> [ 2.085674] Oops: 0000 [#1] SMP NOPTI >>>>>>>>>> [ 2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted >>>>>>>>>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1 >>>>>>>>>> [ 2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018 >>>>>>>>>> [ 2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490 >>>>>>>>>> [...] >>>>>>>>> >>>>>>>>> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657 >>>>>>>>> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this >>>>>>>>> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream. >>>>>>>>> >>>>>>>>> Current upstream kernel is booting fine under Xen, so in general the >>>>>>>>> patch should be fine. Using an upstream kernel built from above commit >>>>>>>>> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine, >>>>>>>>> too. >>>>>>>>> >>>>>>>>> Kirill, are you aware of any prerequisite patch from 4.20 which could be >>>>>>>>> missing in 4.19.5? >>>>>>>> >>>>>>>> I'm not. >>>>>>>> >>>>>>>> Let me look into this. >>>>>>>> >>>>>>> >>>>>>> What is making me suspicious is the failure happening just after >>>>>>> releasing the init memory. Maybe there is an access to .init.data >>>>>>> segment or similar? The native kernel booting could be related to the >>>>>>> usage of 2M mappings not being available in a PV-domain. >>>>>> >>>>>> Did this ever get fixed anywhere that I can properly backport it to the >>>>>> 4.19.y tree? >>>>> >>>>> https://lore.kernel.org/lkml/20181130202328.65359-2-kirill.shutemov@xxxxxxxxxxxxxxx/ >>>>> >>>>> Still pending upstream. Just pinged tglx. >>>> >>>> Thanks, it should have gotten a cc: stable@ tag, but I can watch out for >>>> it... >>> >>> It's upstream now: commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 >> >> Any reason you didn't include this patch in 4.19.14? > > I was catching up on pending patches and got to this yesterday. It > should now be queued up already for the next releases, right? Okay, thanks for confirmation. Juergen
