FAILED: patch "[PATCH] xen: Fix x86 sched_clock() interface for xen" failed to apply to 4.14-stable tree

PATCH [email protected] 4 participants 7 messages Jan 21, 2019 – Jan 23, 2019

Subsystems (4)

Stable branch x86 Xen hypervisor interface Xen hypervisor x86

lore

Share & tools

lore

[email protected]

author maintainer

2019-01-21 09:58 UTC #0 lore raw

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 <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 867cefb4cb1012f42cada1c7d1f35ac8dd276071 Mon Sep 17 00:00:00 2001
From: Juergen Gross <[email protected]>
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 <[email protected]> # 4.11

Reported-by Hans van Kranenburg <[email protected]>

Signed-off-by Juergen Gross <[email protected]>

Tested-by Hans van Kranenburg <[email protected]>

Signed-off-by Boris Ostrovsky <[email protected]>

arch/x86/xen/time.c +9 -3

index 72bf446c3fee..6e29794573b7 100644
@@ -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)

drivers/xen/events/events_base.c +1 -1

index 93194f3e7540..117e76b2f939 100644
@@ -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);
 	}

Boris Ostrovsky

reviewer

2019-01-22 22:08 UTC #1 lore raw

Quoted 4 lines · On 1/21/19 4:58 AM, [email protected] 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 <[email protected]>.

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

Hans van Kranenburg

2019-01-22 22:15 UTC #2 lore raw

Quoted 11 lines · Boris Ostrovsky

Quoted 4 lines · On 1/21/19 4:58 AM, [email protected] 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 <[email protected]>.
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

Signature · 1 line

Hans van Kranenburg

Hans van Kranenburg

2019-01-22 22:27 UTC #3 lore raw

Quoted 10 lines · Hans van Kranenburg

Quoted 9 lines · Boris Ostrovsky
Quoted 4 lines · On 1/21/19 4:58 AM, [email protected] 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 <[email protected]>.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.

Quoted 7 lines

Quoted 2 lines
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...

Signature · 1 line

Hans van Kranenburg

Boris Ostrovsky

reviewer

2019-01-22 22:37 UTC #4 lore raw

In reply to Hans van Kranenburg

Quoted 9 lines · Hans van Kranenburg

Quoted 8 lines · Boris Ostrovsky
Quoted 4 lines · On 1/21/19 4:58 AM, [email protected] 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 <[email protected]>.
I am actually not convinced this fix is needed for 4.14 (or earlier). I couldn't reproduce this bug.

Quoted 7 lines

Quoted 2 lines
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

Juergen Gross

maintainer

2019-01-23 08:23 UTC #5 lore raw

Quoted 12 lines · Boris Ostrovsky

Quoted 11 lines · Hans van Kranenburg
Quoted 10 lines · Boris Ostrovsky
Quoted 4 lines · On 1/21/19 4:58 AM, [email protected] 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 <[email protected]>.
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.

Quoted 7 lines

Quoted 5 lines
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

[email protected]

author maintainer

2019-01-23 09:22 UTC #6 lore raw

Quoted 43 lines · Juergen Gross

Quoted 12 lines · Boris Ostrovsky
Quoted 11 lines · Hans van Kranenburg
Quoted 10 lines · Boris Ostrovsky
Quoted 4 lines · On 1/21/19 4:58 AM, [email protected] 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 <[email protected]>.
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.
Quoted 7 lines
Quoted 5 lines
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

Quoted 7 lines

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