------- Comment From [email protected] 2020-09-23 15:37 EDT------- (In reply to comment #161) > While working on this bug a patched kernel was created and made available > here: > https://people.canonical.com/~fheimes/lp1896726/ > But it's a patched groovy kernel only, since the commit/patch doesn't > cleanly apply to focal master-next: > > git apply --stat > ~/0001-mm-gup-fix-gup_fast-with-dynamic-page-table-folding.patch > arch/s390/include/asm/pgtable.h | 42 > ++++++++++++++++++++++++++++----------- > include/linux/pgtable.h | 10 +++++++++ > mm/gup.c | 18 ++++++++--------- > 3 files changed, 49 insertions(+), 21 deletions(-) > > git apply --check > ~/0001-mm-gup-fix-gup_fast-with-dynamic-page-table-folding.patch > error: patch failed: arch/s390/include/asm/pgtable.h:1260 > error: arch/s390/include/asm/pgtable.h: patch does not apply > error: include/linux/pgtable.h: No such file or directory > > Please always check if a patch/commit applies cleanly to the master-next > tree of the target Ubuntu kernel releases. If not double check if any > further commits are needed or if a even a backport is required. > > There is btw. a significant regression risk associated to this patch, since > it touches general memory management (page table handling and address > translation) and gup code - and this includes common code, where special > care taking is needed, since it may potentially affect millions of > installations across all supported platforms. > > Hence my recommendation is to bring this in with the help of an upstream > stable release update > (https://www.kernel.org/doc/html/v5.4/process/stable-kernel-rules.html) to > upstream kernel 5.4 - which will then be (more or less) automatically be > picked up by the Canonical kernel team for focal.
This conflict was already noticed by stable maintainer, see https://lore.kernel.org/stable/[email protected]/ An adjusted version of the patch was sent for v5.4 stable, see https://lore.kernel.org/stable/patch-1.thread-41918b.git-41918be365c0 [email protected]/ Therefore, our expectation is that this will now go in to v5.4 stable via the normal process. Of course, you could also take the adjusted version from the link above. Regarding the regression risk, while the patch does touch scary common memory management code, it will have absolutely no effect on other architectures than s390. This is ensured by the fact that only s390 provides / implements the new helper functions. And for s390, this actually is a critical (and carefully tested) fix for a (previous) regression, so it can hardly get any more regressive... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1896726 Title: [UBUNTU 20.04.1]Secure guest (qemu) crash during boot (mostly) but also while running workload (rare) (secure execution) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Triaged Status in linux source package in Focal: Incomplete Status in linux source package in Groovy: Triaged Bug description: Secure Execution with Ubuntu 20.04, secure guest crash during boot from time to time, crashed guest went into Shufoff state instead of Crashed state (<on_crash>preserve is set), so I can't get a dump. libvirt log file: 2020-04-21T16:35:39.382999Z qemu-system-s390x: Guest says index 19608 is available 2020-04-21 16:35:44.831+0000: shutting down, reason=crashed ---uname output--- Linux ubu204uclg1002 5.4.0-25-generic #29-Ubuntu SMP Fri Apr 17 15:05:32 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = z15 8561 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- I have a setup with 72 KVM guests which I can start in secure or non-secure mode. Starting all of them in secure mode back to back results in a number of guests (4..8) in Shutoff state and reason=crashed in the libvirt log. I can manually start the guest again.... no problem. Different guests are failing. Host and guests are on latest Ubuntu 20.04. The supposed fix (kernel memory management) has landed in Andrew Mortons mm tree https://lore.kernel.org/mm-commits/20200916003608.ib4ln%[email protected]/T/#u Please note: while this was found with secure execution, the bug is actually present for non-KVM workloads as well. The complete patch is this: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a338e69ba37286c0fc300ab7e6fa0227e6ca68b1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1896726/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
