A recent change in mc146818_get_time() resulted in WARN splats when booting a Xen PV guest.
The main reason is that there is a code path resulting in accessing a RTC device which is not present, which has been made obvious by a call of WARN() in this case.
This small series is fixing this issue by:
- avoiding the RTC device access from drivers/base/power/trace.c in cast there is no legacy RTC device available - resetting the availability flag of a legacy RTC device for Xen PV guests
Juergen Gross (2): PM: base: power: don't try to use non-existing RTC for storing data xen: reset legacy rtc flag for PV domU
arch/x86/xen/enlighten_pv.c | 7 +++++++ drivers/base/power/trace.c | 10 ++++++++++ 2 files changed, 17 insertions(+)
In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume.
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com --- drivers/base/power/trace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a97f33d0c59f..b7c80849455c 100644 --- a/drivers/base/power/trace.c +++ b/drivers/base/power/trace.c @@ -13,6 +13,7 @@ #include <linux/export.h> #include <linux/rtc.h> #include <linux/suspend.h> +#include <linux/init.h>
#include <linux/mc146818rtc.h>
@@ -165,6 +166,9 @@ void generate_pm_trace(const void *tracedata, unsigned int user) const char *file = *(const char **)(tracedata + 2); unsigned int user_hash_value, file_hash_value;
+ if (!x86_platform.legacy.rtc) + return 0; + user_hash_value = user % USERHASH; file_hash_value = hash_string(lineno, file, FILEHASH); set_magic_time(user_hash_value, file_hash_value, dev_hash_value); @@ -267,6 +271,9 @@ static struct notifier_block pm_trace_nb = {
static int __init early_resume_init(void) { + if (!x86_platform.legacy.rtc) + return 0; + hash_value_early_read = read_magic_time(); register_pm_notifier(&pm_trace_nb); return 0; @@ -277,6 +284,9 @@ static int __init late_resume_init(void) unsigned int val = hash_value_early_read; unsigned int user, file, dev;
+ if (!x86_platform.legacy.rtc) + return 0; + user = val % USERHASH; val = val / USERHASH; file = val % FILEHASH;
On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume.
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com
drivers/base/power/trace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a97f33d0c59f..b7c80849455c 100644 --- a/drivers/base/power/trace.c +++ b/drivers/base/power/trace.c @@ -13,6 +13,7 @@ #include <linux/export.h> #include <linux/rtc.h> #include <linux/suspend.h> +#include <linux/init.h> #include <linux/mc146818rtc.h> @@ -165,6 +166,9 @@ void generate_pm_trace(const void *tracedata, unsigned int user) const char *file = *(const char **)(tracedata + 2); unsigned int user_hash_value, file_hash_value;
- if (!x86_platform.legacy.rtc)
return 0;
Why does the driver core code here care about a platform/arch-specific thing at all? Did you just break all other arches?
thanks,
greg k-h
On 03.09.21 10:56, Greg Kroah-Hartman wrote:
On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume.
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com
drivers/base/power/trace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a97f33d0c59f..b7c80849455c 100644 --- a/drivers/base/power/trace.c +++ b/drivers/base/power/trace.c @@ -13,6 +13,7 @@ #include <linux/export.h> #include <linux/rtc.h> #include <linux/suspend.h> +#include <linux/init.h> #include <linux/mc146818rtc.h> @@ -165,6 +166,9 @@ void generate_pm_trace(const void *tracedata, unsigned int user) const char *file = *(const char **)(tracedata + 2); unsigned int user_hash_value, file_hash_value;
- if (!x86_platform.legacy.rtc)
return 0;Why does the driver core code here care about a platform/arch-specific thing at all? Did you just break all other arches?
This file is only compiled for x86. It depends on CONFIG_PM_TRACE_RTC, which has a "depends on X86" attribute.
Juergen
On Fri, Sep 03, 2021 at 11:01:58AM +0200, Juergen Gross wrote:
On 03.09.21 10:56, Greg Kroah-Hartman wrote:
On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume.
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com
drivers/base/power/trace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a97f33d0c59f..b7c80849455c 100644 --- a/drivers/base/power/trace.c +++ b/drivers/base/power/trace.c @@ -13,6 +13,7 @@ #include <linux/export.h> #include <linux/rtc.h> #include <linux/suspend.h> +#include <linux/init.h> #include <linux/mc146818rtc.h> @@ -165,6 +166,9 @@ void generate_pm_trace(const void *tracedata, unsigned int user) const char *file = *(const char **)(tracedata + 2); unsigned int user_hash_value, file_hash_value;
- if (!x86_platform.legacy.rtc)
return 0;Why does the driver core code here care about a platform/arch-specific thing at all? Did you just break all other arches?
This file is only compiled for x86. It depends on CONFIG_PM_TRACE_RTC, which has a "depends on X86" attribute.
Odd, and not obvious at all :(
Ok, I'll let Rafael review this...
On Fri, Sep 3, 2021 at 11:02 AM Juergen Gross jgross@suse.com wrote:
On 03.09.21 10:56, Greg Kroah-Hartman wrote:
On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume.
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com
drivers/base/power/trace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a97f33d0c59f..b7c80849455c 100644 --- a/drivers/base/power/trace.c +++ b/drivers/base/power/trace.c @@ -13,6 +13,7 @@ #include <linux/export.h> #include <linux/rtc.h> #include <linux/suspend.h> +#include <linux/init.h>
#include <linux/mc146818rtc.h>
@@ -165,6 +166,9 @@ void generate_pm_trace(const void *tracedata, unsigned int user) const char *file = *(const char **)(tracedata + 2); unsigned int user_hash_value, file_hash_value;
- if (!x86_platform.legacy.rtc)
return 0;Why does the driver core code here care about a platform/arch-specific thing at all? Did you just break all other arches?
This file is only compiled for x86. It depends on CONFIG_PM_TRACE_RTC, which has a "depends on X86" attribute.
This feature uses the CMOS RTC memory to store data, so if that memory is not present, it's better to avoid using it.
Please feel free to add
Reviewed-by: Rafael J. Wysocki rafael@kernel.org
to this patch or let me know if you want me to take it.
On 06.09.21 19:07, Rafael J. Wysocki wrote:
On Fri, Sep 3, 2021 at 11:02 AM Juergen Gross jgross@suse.com wrote:
On 03.09.21 10:56, Greg Kroah-Hartman wrote:
On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume.
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com
drivers/base/power/trace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a97f33d0c59f..b7c80849455c 100644 --- a/drivers/base/power/trace.c +++ b/drivers/base/power/trace.c @@ -13,6 +13,7 @@ #include <linux/export.h> #include <linux/rtc.h> #include <linux/suspend.h> +#include <linux/init.h>
#include <linux/mc146818rtc.h>
@@ -165,6 +166,9 @@ void generate_pm_trace(const void *tracedata, unsigned int user) const char *file = *(const char **)(tracedata + 2); unsigned int user_hash_value, file_hash_value;
- if (!x86_platform.legacy.rtc)
return 0;Why does the driver core code here care about a platform/arch-specific thing at all? Did you just break all other arches?
This file is only compiled for x86. It depends on CONFIG_PM_TRACE_RTC, which has a "depends on X86" attribute.
This feature uses the CMOS RTC memory to store data, so if that memory is not present, it's better to avoid using it.
Please feel free to add
Reviewed-by: Rafael J. Wysocki rafael@kernel.org
Thanks!
to this patch or let me know if you want me to take it.
No, I can take it with the other patch of this small series, thanks.
Juergen
A Xen PV guest doesn't have a legacy RTC device, so reset the legacy RTC flag. Otherwise the following WARN splat will occur at boot:
[ 1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210 [ 1.333404] Modules linked in: [ 1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0-rc7-default+ #282 [ 1.333404] RIP: e030:mc146818_get_time+0x1be/0x210 [ 1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff [ 1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002 [ 1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000 [ 1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d [ 1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000 [ 1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200 [ 1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4 [ 1.333404] FS: 0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000 [ 1.333404] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660 [ 1.333404] Call Trace: [ 1.333404] ? wakeup_sources_sysfs_init+0x30/0x30 [ 1.333404] ? rdinit_setup+0x2b/0x2b [ 1.333404] early_resume_init+0x23/0xa4 [ 1.333404] ? cn_proc_init+0x36/0x36 [ 1.333404] do_one_initcall+0x3e/0x200 [ 1.333404] kernel_init_freeable+0x232/0x28e [ 1.333404] ? rest_init+0xd0/0xd0 [ 1.333404] kernel_init+0x16/0x120 [ 1.333404] ret_from_fork+0x1f/0x30
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com --- arch/x86/xen/enlighten_pv.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 753f63734c13..349f780a1567 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1214,6 +1214,11 @@ static void __init xen_dom0_set_legacy_features(void) x86_platform.legacy.rtc = 1; }
+static void __init xen_domu_set_legacy_features(void) +{ + x86_platform.legacy.rtc = 0; +} + /* First C function to be called on Xen boot */ asmlinkage __visible void __init xen_start_kernel(void) { @@ -1359,6 +1364,8 @@ asmlinkage __visible void __init xen_start_kernel(void) add_preferred_console("xenboot", 0, NULL); if (pci_xen) x86_init.pci.arch_init = pci_xen_init; + x86_platform.set_legacy_features = + xen_domu_set_legacy_features; } else { const struct dom0_vga_console_info *info = (void *)((char *)xen_start_info +
On 9/3/21 4:49 AM, Juergen Gross wrote:
A Xen PV guest doesn't have a legacy RTC device, so reset the legacy RTC flag. Otherwise the following WARN splat will occur at boot:
[ 1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210 [ 1.333404] Modules linked in: [ 1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0-rc7-default+ #282 [ 1.333404] RIP: e030:mc146818_get_time+0x1be/0x210 [ 1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff [ 1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002 [ 1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000 [ 1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d [ 1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000 [ 1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200 [ 1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4 [ 1.333404] FS: 0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000 [ 1.333404] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660 [ 1.333404] Call Trace: [ 1.333404] ? wakeup_sources_sysfs_init+0x30/0x30 [ 1.333404] ? rdinit_setup+0x2b/0x2b [ 1.333404] early_resume_init+0x23/0xa4 [ 1.333404] ? cn_proc_init+0x36/0x36 [ 1.333404] do_one_initcall+0x3e/0x200 [ 1.333404] kernel_init_freeable+0x232/0x28e [ 1.333404] ? rest_init+0xd0/0xd0 [ 1.333404] kernel_init+0x16/0x120 [ 1.333404] ret_from_fork+0x1f/0x30
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs") ?
Reviewed-by: Boris Ostrovsky boris.ostrovsky@oracle.com
On 08.09.21 16:54, Boris Ostrovsky wrote:
On 9/3/21 4:49 AM, Juergen Gross wrote:
A Xen PV guest doesn't have a legacy RTC device, so reset the legacy RTC flag. Otherwise the following WARN splat will occur at boot:
[ 1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210 [ 1.333404] Modules linked in: [ 1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0-rc7-default+ #282 [ 1.333404] RIP: e030:mc146818_get_time+0x1be/0x210 [ 1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff [ 1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002 [ 1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000 [ 1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d [ 1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000 [ 1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200 [ 1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4 [ 1.333404] FS: 0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000 [ 1.333404] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660 [ 1.333404] Call Trace: [ 1.333404] ? wakeup_sources_sysfs_init+0x30/0x30 [ 1.333404] ? rdinit_setup+0x2b/0x2b [ 1.333404] early_resume_init+0x23/0xa4 [ 1.333404] ? cn_proc_init+0x36/0x36 [ 1.333404] do_one_initcall+0x3e/0x200 [ 1.333404] kernel_init_freeable+0x232/0x28e [ 1.333404] ? rest_init+0xd0/0xd0 [ 1.333404] kernel_init+0x16/0x120 [ 1.333404] ret_from_fork+0x1f/0x30
Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross jgross@suse.com
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs") ?
I don't think so. Its rather:
Fixes: 8d152e7a5c7537 ("x86/rtc: Replace paravirt rtc check with platform legacy quirk")
as this was the commit leading to domUs having the rtc capability being set.
Reviewed-by: Boris Ostrovsky boris.ostrovsky@oracle.com
Thanks,
Juergen
linux-stable-mirror@lists.linaro.org
-
Boris Ostrovsky -
Greg Kroah-Hartman -
Juergen Gross -
Rafael J. Wysocki