FAILED: patch "[PATCH] xen: Fix x86 sched_clock() interface for xen" failed to apply to 4.14-stable tree
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 867cefb4cb1012f42cada1c7d1f35ac8dd276071 Mon Sep 17 00:00:00 2001
From: Juergen Gross jgross@suse.com Date: Mon, 14 Jan 2019 13:44:13 +0100 Subject: [PATCH] xen: Fix x86 sched_clock() interface for xen
Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") broke Xen guest time handling across migration:
[ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 187.251137] OOM killer disabled. [ 187.251137] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 187.252299] suspending xenstore... [ 187.266987] xen:grant_table: Grant tables using version 1 layout [18446743811.706476] OOM killer enabled. [18446743811.706478] Restarting tasks ... done. [18446743811.720505] Setting capacity to 16777216
Fix that by setting xen_sched_clock_offset at resume time to ensure a monotonic clock value.
[boris: replaced pr_info() with pr_info_once() in xen_callback_vector() to avoid printing with incorrect timestamp during resume (as we haven't re-adjusted the clock yet)]
Fixes: f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") Cc: stable@vger.kernel.org # 4.11 Reported-by: Hans van Kranenburg hans.van.kranenburg@mendix.com Signed-off-by: Juergen Gross jgross@suse.com Tested-by: Hans van Kranenburg hans.van.kranenburg@mendix.com Signed-off-by: Boris Ostrovsky boris.ostrovsky@oracle.com
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 72bf446c3fee..6e29794573b7 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -361,8 +361,6 @@ void xen_timer_resume(void) { int cpu;
- pvclock_resume(); - if (xen_clockevent != &xen_vcpuop_clockevent) return;
@@ -379,12 +377,15 @@ static const struct pv_time_ops xen_time_ops __initconst = { };
static struct pvclock_vsyscall_time_info *xen_clock __read_mostly; +static u64 xen_clock_value_saved;
void xen_save_time_memory_area(void) { struct vcpu_register_time_memory_area t; int ret;
+ xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset; + if (!xen_clock) return;
@@ -404,7 +405,7 @@ void xen_restore_time_memory_area(void) int ret;
if (!xen_clock) - return; + goto out;
t.addr.v = &xen_clock->pvti;
@@ -421,6 +422,11 @@ void xen_restore_time_memory_area(void) if (ret != 0) pr_notice("Cannot restore secondary vcpu_time_info (err %d)", ret); + +out: + /* Need pvclock_resume() before using xen_clocksource_read(). */ + pvclock_resume(); + xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved; }
static void xen_setup_vsyscall_time_info(void) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 93194f3e7540..117e76b2f939 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -1650,7 +1650,7 @@ void xen_callback_vector(void) xen_have_vector_callback = 0; return; } - pr_info("Xen HVM callback vector for event delivery is enabled\n"); + pr_info_once("Xen HVM callback vector for event delivery is enabled\n"); alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, xen_hvm_callback_vector); }
On 1/21/19 4:58 AM, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.
I think we also need Pasha Tatashin's time series (38669ba205d1 and friends) for the problem to show up.
-boris
On 1/22/19 11:08 PM, Boris Ostrovsky wrote:
On 1/21/19 4:58 AM, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.
I think we also need Pasha Tatashin's time series (38669ba205d1 and friends) for the problem to show up.
It happens after f94c8d1169, and it was really easy to reproduce for me (or not to) during bisecting.
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg02356.html
On 1/22/19 11:15 PM, Hans van Kranenburg wrote:
On 1/22/19 11:08 PM, Boris Ostrovsky wrote:
On 1/21/19 4:58 AM, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.
I think we also need Pasha Tatashin's time series (38669ba205d1 and friends) for the problem to show up.
It happens after f94c8d1169, and it was really easy to reproduce for me (or not to) during bisecting.
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg02356.html
Wait, I have been horsing around in the 'normal' linux timeline of course with the bisecting, hopping from rc to rc, and not in the latest linux-stable versions of 4.14 etc. So, it's possible that things happened in there over time.
But, in that case it would also be suspicious that some other commit would be covering up the issue, while I started out the investigation with 4.19...
On 1/22/19 5:15 PM, Hans van Kranenburg wrote:
On 1/22/19 11:08 PM, Boris Ostrovsky wrote:
On 1/21/19 4:58 AM, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.
I think we also need Pasha Tatashin's time series (38669ba205d1 and friends) for the problem to show up.
It happens after f94c8d1169, and it was really easy to reproduce for me (or not to) during bisecting.
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg02356.html
Hmm.. I ran 4.14.91 and see no problems.
-boris
On 22/01/2019 23:37, Boris Ostrovsky wrote:
On 1/22/19 5:15 PM, Hans van Kranenburg wrote:
On 1/22/19 11:08 PM, Boris Ostrovsky wrote:
On 1/21/19 4:58 AM, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.
I think we also need Pasha Tatashin's time series (38669ba205d1 and friends) for the problem to show up.
It happens after f94c8d1169, and it was really easy to reproduce for me (or not to) during bisecting.
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg02356.html
Hmm.. I ran 4.14.91 and see no problems.
dmesg from current linux-4.14.y branch:
[ 53.155208] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 53.156614] OOM killer disabled. [ 53.156616] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 53.171864] suspending xenstore... [ 53.212606] xen:events: Xen HVM callback vector for event delivery is enabled [ 53.212606] Xen Platform PCI: I/O protocol version 1 [ 53.212606] xen:grant_table: Grant tables using version 1 layout [ 53.212606] xen: --> irq=9, pirq=16 [ 53.212606] xen: --> irq=8, pirq=17 [ 53.212606] xen: --> irq=12, pirq=18 [ 53.212606] xen: --> irq=1, pirq=19 [ 53.212606] xen: --> irq=6, pirq=20 [ 53.212606] xen: --> irq=24, pirq=21 [18446741328.844150] OOM killer enabled. [18446741328.844153] Restarting tasks ... done. [18446741328.893762] Setting capacity to 16777216
So the issue is present in 4.14. BTW, I have an internal bug report for this issue from 4.12 kernel. :-)
Greg, one question for the backport: the least intrusive way seems to be to add another patch from upstream (commit 38669ba205d178d2d38b). Should I add this patch separately, or do you want me to include it in the backported patch?
Juergen
On Wed, Jan 23, 2019 at 09:23:19AM +0100, Juergen Gross wrote:
On 22/01/2019 23:37, Boris Ostrovsky wrote:
On 1/22/19 5:15 PM, Hans van Kranenburg wrote:
On 1/22/19 11:08 PM, Boris Ostrovsky wrote:
On 1/21/19 4:58 AM, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.
I think we also need Pasha Tatashin's time series (38669ba205d1 and friends) for the problem to show up.
It happens after f94c8d1169, and it was really easy to reproduce for me (or not to) during bisecting.
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg02356.html
Hmm.. I ran 4.14.91 and see no problems.
dmesg from current linux-4.14.y branch:
[ 53.155208] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 53.156614] OOM killer disabled. [ 53.156616] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 53.171864] suspending xenstore... [ 53.212606] xen:events: Xen HVM callback vector for event delivery is enabled [ 53.212606] Xen Platform PCI: I/O protocol version 1 [ 53.212606] xen:grant_table: Grant tables using version 1 layout [ 53.212606] xen: --> irq=9, pirq=16 [ 53.212606] xen: --> irq=8, pirq=17 [ 53.212606] xen: --> irq=12, pirq=18 [ 53.212606] xen: --> irq=1, pirq=19 [ 53.212606] xen: --> irq=6, pirq=20 [ 53.212606] xen: --> irq=24, pirq=21 [18446741328.844150] OOM killer enabled. [18446741328.844153] Restarting tasks ... done. [18446741328.893762] Setting capacity to 16777216
So the issue is present in 4.14. BTW, I have an internal bug report for this issue from 4.12 kernel. :-)
Greg, one question for the backport: the least intrusive way seems to be to add another patch from upstream (commit 38669ba205d178d2d38b). Should I add this patch separately, or do you want me to include it in the backported patch?
Stick to upstream as close as possible, so if it takes 1, or 2, or 10 patches from upstream submit them all. Every time we try to "only take a part of a fix", or "rewrite it to be smaller" we get it wrong. Every time...
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Boris Ostrovsky -
gregkh＠linuxfoundation.org -
Hans van Kranenburg -
Juergen Gross