Re: [kernel] Fix random crashes in x86-64 swsusp

Re: [kernel] Fix random crashes in x86-64 swsusp

[Jan Beulich]

Maybe not really a final version: The __init should remain there if
suspend/resume isn't enabled in the configuration. I'd guess you want
something for this paralleling the __cpuinit/__devinit/module_init stuff
(if these occur very rarely, then doing this inline may of course also
be an acceptable choice). Jan

>>> pavel@suse.cz 07.10.04 00:06:00 >>>
Hi!

fix_processor_context was calling functions marked __init on x86-64;
bad idea. Maybe we should memset freed memory to zero so such bugs are
prevented?

Thanks to Rafael for keeping notifying me about this bug, and someone
get me yet another brown paper bag.

Anyway, this should fix it, please apply,
								Pavel

--- clean-suse/arch/x86_64/ia32/syscall32.c	2004-06-22
12:36:00.000000000 +0200
+++ linux-suse/arch/x86_64/ia32/syscall32.c	2004-10-06
23:58:27.000000000 +0200
@@ -76,7 +76,8 @@
 	
 __initcall(init_syscall32); 
 
-void __init syscall32_cpu_init(void)
+/* May not be __init: called during resume */
+void syscall32_cpu_init(void)
 {
 	if (use_sysenter < 0)
  		use_sysenter = (boot_cpu_data.x86_vendor ==
X86_VENDOR_INTEL);
--- clean-suse/arch/x86_64/kernel/setup64.c	2004-10-05
11:36:21.000000000 +0200
+++ linux-suse/arch/x86_64/kernel/setup64.c	2004-10-06
23:59:08.000000000 +0200
@@ -195,7 +195,8 @@
 char boot_exception_stacks[N_EXCEPTION_STACKS * EXCEPTION_STKSZ] 
 __attribute__((section(".bss.page_aligned")));
 
-void __init syscall_init(void)
+/* May not be marked __init: used by software suspend */
+void syscall_init(void)
 {
 	/* 
 	 * LSTAR and STAR live in a bit strange symbiosis.

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [kernel] Fix random crashes in x86-64 swsusp

[Pavel Machek]

Hi!

> Maybe not really a final version: The __init should remain there if
> suspend/resume isn't enabled in the configuration. I'd guess you want
> something for this paralleling the __cpuinit/__devinit/module_init stuff
> (if these occur very rarely, then doing this inline may of course also
> be an acceptable choice). Jan

I do not think we care enough about those few bytes to make sources
more complex. These functions are really small.
								Pavel

> >>> pavel@suse.cz 07.10.04 00:06:00 >>>
> Hi!
> 
> fix_processor_context was calling functions marked __init on x86-64;
> bad idea. Maybe we should memset freed memory to zero so such bugs are
> prevented?
> 
> Thanks to Rafael for keeping notifying me about this bug, and someone
> get me yet another brown paper bag.
> 
> Anyway, this should fix it, please apply,
> 								Pavel
> 
> --- clean-suse/arch/x86_64/ia32/syscall32.c	2004-06-22
> 12:36:00.000000000 +0200
> +++ linux-suse/arch/x86_64/ia32/syscall32.c	2004-10-06
> 23:58:27.000000000 +0200
> @@ -76,7 +76,8 @@
>  	
>  __initcall(init_syscall32); 
>  
> -void __init syscall32_cpu_init(void)
> +/* May not be __init: called during resume */
> +void syscall32_cpu_init(void)
>  {
>  	if (use_sysenter < 0)
>   		use_sysenter = (boot_cpu_data.x86_vendor ==
> X86_VENDOR_INTEL);
> --- clean-suse/arch/x86_64/kernel/setup64.c	2004-10-05
> 11:36:21.000000000 +0200
> +++ linux-suse/arch/x86_64/kernel/setup64.c	2004-10-06
> 23:59:08.000000000 +0200
> @@ -195,7 +195,8 @@
>  char boot_exception_stacks[N_EXCEPTION_STACKS * EXCEPTION_STKSZ] 
>  __attribute__((section(".bss.page_aligned")));
>  
> -void __init syscall_init(void)
> +/* May not be marked __init: used by software suspend */
> +void syscall_init(void)
>  {
>  	/* 
>  	 * LSTAR and STAR live in a bit strange symbiosis.
> 

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Rafael J. Wysocki]

Hi,

It looks like there's a probel with the kernel preemption vs swsusp:

Stopping tasks: 
=============================================================================|
Freeing 
memory: ......................................................................................................................|
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
..<7>[nosave pfn 
0x5be].............................................................................swsusp: 
Need to copy 17764 pages
suspend: (pages needed: 17764 + 512 free: 113115)
..<7>[nosave pfn 
0x5be].............................................................................swsusp: 
critical section/: done (1)
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
<ffffffff8059b5a6>{cpu_init+38}
PML4 bc83067 PGD bfe9067 PMD 0
Oops: 0000 [1] PREEMPT
CPU 0
Modules linked in: usbserial parport_pc lp parport ipv6 joydev sg st sd_mod 
sr_mod scsi_mod usbhid snd_seq_oss snd_seq_midi_event snd_d
Pid: 19437, comm: hibernate.sh Not tainted 2.6.9-rc3
RIP: 0010:[<ffffffff8059b5a6>] <ffffffff8059b5a6>{cpu_init+38}
RSP: 0018:000001000fe93e40  EFLAGS: 00010002
RAX: 0000000000000089 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000001000fe93e6c RDI: ffffffff80442f50
RBP: 0000000000000004 R08: 0000000000000000 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff80455d80
R13: 0000000000000002 R14: 0000002a955a4000 R15: 0000000000000000
FS:  0000002a95d330a0(0000) GS:ffffffff8058fb40(0000) knlGS:0000000057c90bb0
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006e0
Process hibernate.sh (pid: 19437, threadinfo 000001000fe92000, task 
0000010018cb92d0)
Stack: ffffffff80121b49 0000000000000000 0000000000000004 8000895060002080
       00000000ffffffff ffffffff8050bfa0 ffffffff80121d38 0000000000000000
       ffffffff80166dd3 0000000000000000
Call Trace:<ffffffff80121b49>{fix_processor_context+137} 
<ffffffff80121d38>{__restore_processor_state+120}
       <ffffffff80166dd3>{swsusp_suspend+19} 
<ffffffff8016810a>{pm_suspend_disk+90}
       <ffffffff80165b84>{enter_state+68} 
<ffffffff802ceac5>{acpi_system_write_sleep+100}
       <ffffffff8019cf14>{vfs_write+228} <ffffffff8019d053>{sys_write+83}
       <ffffffff801110da>{system_call+126}

Code: 0a 2b 20 2a 20 46 6f 72 20 65 78 61 6d 70 6c 65 2c 20 6f 6e
RIP <ffffffff8059b5a6>{cpu_init+38} RSP <000001000fe93e40>
CR2: 0000000000000000
 <6>note: hibernate.sh[19437] exited with preempt_count 1
bad: scheduling while atomic!

Call Trace:<ffffffff803d2b7e>{schedule+94} <ffffffff80183982>{unmap_vmas+1666}
       <ffffffff80187915>{exit_mmap+293} <ffffffff8013a960>{mmput+272}
       <ffffffff80143724>{do_exit+820} <ffffffff80112449>{oops_end+201}
       <ffffffff80125a0f>{do_page_fault+1247} <ffffffff8013d66d>{printk+141}
       <ffffffff8013d66d>{printk+141} <ffffffff8011198d>{error_exit+0}
       <ffffffff8059b5a6>{cpu_init+38} 
<ffffffff80121b49>{fix_processor_context+137}
       <ffffffff80121d38>{__restore_processor_state+120} 
<ffffffff80166dd3>{swsusp_suspend+19}
       <ffffffff8016810a>{pm_suspend_disk+90} 
<ffffffff80165b84>{enter_state+68}
       <ffffffff802ceac5>{acpi_system_write_sleep+100} 
<ffffffff8019cf14>{vfs_write+228}
       <ffffffff8019d053>{sys_write+83} <ffffffff801110da>{system_call+126}

The system is an x86-64 box.  Please let me know if you need more information.  
Sorry for the noise if it's a known issue.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Rafael J. Wysocki]

On Wednesday 06 of October 2004 10:54, Pavel Machek wrote:
> Hi!
> 
> > > > It looks like there's a probel with the kernel preemption vs swsusp:
> > > 
> > > It is not in kernel preemption, see that NULL pointer dereference? Try
> > > this one...
> > [-- snip --]
> > 
> > Is it against -mm?  It does not apply cleanly to -rc3, so I've applied it 
> > manually.
> 
> It was against -suse... Did it help?

I just can't say it didn't right now.  The Oops was not readily reproducible 
anyway, so I need to do some more suspend/resume testing.  I'll let you 
know. ;-)

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Pavel Machek]

Hi!

> > > > > It looks like there's a probel with the kernel preemption vs swsusp:
> > > > 
> > > > It is not in kernel preemption, see that NULL pointer dereference? Try
> > > > this one...
> > > [-- snip --]
> > > 
> > > Is it against -mm?  It does not apply cleanly to -rc3, so I've applied it 
> > > manually.
> > 
> > It was against -suse... Did it help?
> 
> I just can't say it didn't right now.  The Oops was not readily reproducible 
> anyway, so I need to do some more suspend/resume testing.  I'll let you 
> know. ;-)

Ahha, thats likely another problem, then. The one this fixes is 100%
reproducible...

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Rafael J. Wysocki]

On Wednesday 06 of October 2004 12:12, Pavel Machek wrote:
> Hi!
> 
> > > > > > It looks like there's a probel with the kernel preemption vs 
swsusp:
> > > > > 
> > > > > It is not in kernel preemption, see that NULL pointer dereference? 
Try
> > > > > this one...
> > > > [-- snip --]
> > > > 
> > > > Is it against -mm?  It does not apply cleanly to -rc3, so I've applied 
it 
> > > > manually.
> > > 
> > > It was against -suse... Did it help?
> > 
> > I just can't say it didn't right now.  The Oops was not readily 
reproducible 
> > anyway, so I need to do some more suspend/resume testing.  I'll let you 
> > know. ;-)
> 
> Ahha, thats likely another problem, then. The one this fixes is 100%
> reproducible...

You are right, it doesn't help.  Here's another trace for a non-preemptible 
kernel with the patch applied:

Stopping tasks: 
=================================================================|
Freeing 
memory: .....................................................................................................................|
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
..<7>[nosave pfn 
0x58c]...................................................................................................swsusp: 
Nees
suspend: (pages needed: 44159 + 512 free: 86720)
..<7>[nosave pfn 
0x58c].....................................................................................................swsusp: 
c)
Unable to handle kernel paging request at 000000ff9f2f9f09 RIP:
<ffffffff805693f7>{syscall_init+7}
PML4 0
Oops: 0000 [1]
CPU 0
Modules linked in: usbserial parport_pc lp parport joydev sg st sd_mod sr_mod 
scsi_mod usbhid snd_seq_oss snd_seq_midi_event snd_seq d
Pid: 16652, comm: hibernate.sh Not tainted 2.6.9-rc3
RIP: 0010:[<ffffffff805693f7>] <ffffffff805693f7>{syscall_init+7}
RSP: 0018:0000010003301e40  EFLAGS: 00010082
RAX: 0000000000000089 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000b1ff96ac RSI: 0000010003301e68 RDI: ffffffff80412190
RBP: 0000000000000004 R08: 0000000000000000 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff80424fc0
R13: 0000000000000002 R14: 0000002a955a4000 R15: 0000000000000000
FS:  0000002a95d330a0(0000) GS:ffffffff8055eb40(0000) knlGS:0000000056055200
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000ff9f2f9f09 CR3: 0000000000101000 CR4: 00000000000006e0
Process hibernate.sh (pid: 16652, threadinfo 0000010003300000, task 
000001000f35c0f0)
Stack: ffffffff801209b9 0000000000000000 0000000000000004 8000894d50002080
       00000000ffffffff ffffffff804dafa0 ffffffff80120c28 0000000000000000
       ffffffff80161003 0000000000000000
Call Trace:<ffffffff801209b9>{fix_processor_context+137} 
<ffffffff80120c28>{__restore_processor_state+120}
       <ffffffff80161003>{swsusp_suspend+19} 
<ffffffff8016216a>{pm_suspend_disk+90}
       <ffffffff8015fd54>{enter_state+68} 
<ffffffff802adb4d>{acpi_system_write_sleep+100}
       <ffffffff80193854>{vfs_write+228} <ffffffff80193993>{sys_write+83}
       <ffffffff80110c72>{system_call+126}

Code: ff a6 a1 80 ff 9b 9c 75 ff 97 96 74 ff a1 a0 7e ff 9e 9c 7d
RIP <ffffffff805693f7>{syscall_init+7} RSP <0000010003301e40>
CR2: 000000ff9f2f9f09

It seems that I need to run X to reproduce it and it also seems that it's more 
likely to happen if I run some X apps and close them all before suspending.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Fix random crashes in x86-64 swsusp

[Pavel Machek]

Hi!

fix_processor_context was calling functions marked __init on x86-64;
bad idea. Maybe we should memset freed memory to zero so such bugs are
prevented?

Thanks to Rafael for keeping notifying me about this bug, and someone
get me yet another brown paper bag.

Anyway, this should fix it, please apply,
								Pavel

--- clean-suse/arch/x86_64/ia32/syscall32.c	2004-06-22 12:36:00.000000000 +0200
+++ linux-suse/arch/x86_64/ia32/syscall32.c	2004-10-06 23:58:27.000000000 +0200
@@ -76,7 +76,8 @@
 	
 __initcall(init_syscall32); 
 
-void __init syscall32_cpu_init(void)
+/* May not be __init: called during resume */
+void syscall32_cpu_init(void)
 {
 	if (use_sysenter < 0)
  		use_sysenter = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL);
--- clean-suse/arch/x86_64/kernel/setup64.c	2004-10-05 11:36:21.000000000 +0200
+++ linux-suse/arch/x86_64/kernel/setup64.c	2004-10-06 23:59:08.000000000 +0200
@@ -195,7 +195,8 @@
 char boot_exception_stacks[N_EXCEPTION_STACKS * EXCEPTION_STKSZ] 
 __attribute__((section(".bss.page_aligned")));
 
-void __init syscall_init(void)
+/* May not be marked __init: used by software suspend */
+void syscall_init(void)
 {
 	/* 
 	 * LSTAR and STAR live in a bit strange symbiosis.

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [kernel] Fix random crashes in x86-64 swsusp

[Andi Kleen]

On Thu, Oct 07, 2004 at 12:06:00AM +0200, Pavel Machek wrote:
> Hi!
> 
> fix_processor_context was calling functions marked __init on x86-64;
> bad idea. Maybe we should memset freed memory to zero so such bugs are
> prevented?

It's called CONFIG_INIT_DEBUG. But nobody uses it.

-Andi