linux-kernel - [BUG] Code reordering in swsusp breaks suspend on SMP systems

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-next>] [day] [month] [year] [list]

Message-Id: <200703211840.53242.maximlevitsky@gmail.com>
Date:	Wed, 21 Mar 2007 18:40:52 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Pavel Machek <pavel@....cz>, "Rafael J. Wysocki" <rjw@...k.pl>
Subject: [BUG] Code reordering in swsusp breaks suspend on SMP systems

Hi,

Starting with 2.6.21-rc1 suspend to ram and disk doesn't work anymore on my system.

I did a git-bisect and found that those commits break it:

e3c7db621bed4afb8e231cb005057f2feb5db557 - [PATCH] [PATCH] PM: Change code ordering in main.c
ed746e3b18f4df18afa3763155972c5835f284c5 - [PATCH] [PATCH] swsusp: Change code ordering in disk.c
259130526c267550bc365d3015917d90667732f1 - [PATCH] [PATCH] swsusp: Change code ordering in user.c

I already reported about it, but now i know the reason why suspend breaks.

The problem is that both cpu_up/cpu_down were allowed to sleep until now, 
and it did work because those functions could be called only in process context
(the one that writes to /sys/devices/system/cpu/cpu*/online) or  idle thread  that does smp_init()).

But now they are called _after_ all tasks were suspended, so if cpu_down tries for example to take a lock
that is taken by different process, it can't since the different proccess is frozen and can't release the lock.

I tested this and all results are positive:

I disabled 2nd cpu by hand, and then suspend to ram was successfull.
Suspend to disk went correctly, but it hang on resume, and I know why.
It hang in old kernel trying to disable 2nd cpu that was enabled by it.

I was able using kdb to confirm that this is true because it was still possible to enter kdb, and see that
idle thread (swapper) was active, and uswsusp was waiting on mutex inside workqueue_cpu_callback.

The solution for this problem seems to be ether complete audit of code that uses register_cpu_notifier,
to ensure that it doesn't sleep. 
Also documentation should be changed to note about it.

Or, it is also possible to revert this change.

	Regards,
		Maxim Levitsky

-
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/