linux-kernel - Re: [Bug #11989] Suspend failure on NForce4-based boards due to chanes in stop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Nov 2008 12:31:34 +0100
From:	Heiko Carstens <heiko.carstens@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Oleg Nesterov <oleg@...hat.com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Bug #11989] Suspend failure on NForce4-based boards due to
	chanes in stop_machine

On Tue, Nov 11, 2008 at 11:52:14AM +0100, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw@...k.pl> wrote:
> 
> > However, it is reproducible by doing
> > 
> > # echo core > /sys/power/pm_test
> > 
> > and repeating
> > 
> > # echo disk > /sys/power/state
> > 
> > for a couple of times, in which case the last two lines printed to the console
> > before a (solid) hang are:
> > 
> > SMP alternatives: switching to SMP code
> > Booting processor 1 APIC 0x1 ip 0x6000
> > 
> > So, it evidently fails while re-enabling the non-boot CPU and not 
> > during disabling it as I thought before.
> > 
> > With commit c9583e55fa2b08a230c549bd1e3c0bde6c50d9cc reverted the 
> > issue is not reproducible any more.
> 
> [ Cc:-ed workqueue/locking/suspend-race-condition experts. ]
> 
> Seems like the new kernel/stop_machine.c logic has a race for the test 
> sequence above. (Below is the bisected commit again, maybe the race is 
> visible via email review as well.)

FWIW, I tried to reproduce this on s390 and got the following:

A process that would do nothing but onlining/offlining cpus would get
stuck after a while:

 0 schedule+842 [0x342522]
 1 schedule_timeout+200 [0x342ec4]
 2 wait_for_common+362 [0x341fd6]
 3 wait_for_completion+54 [0x342146]
 4 __synchronize_sched+80 [0x81670]
 5 cpu_down+172 [0x33c030]
 6 store_online+96 [0x33c488]
 7 sysdev_store+52 [0x1bda84]
 8 sysfs_write_file+242 [0x1350ba]
 9 vfs_write+176 [0xd2028]
10 sys_write+82 [0xd21ea]
11 sysc_noemu+16 [0x269d8]

All cpus are in cpu_idle and no other task in state TASK_INTERRUPTIBLE
or TASK_UNINTERRUPTIBLE. However it would continue to work as soon as
I login into the system or generate a console interrupt.
I'm going to look into the dump and see if I can figure out what is
broken here.
Dunno if it is the same bug or something else.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/