linux-kernel - Re: T400 suspend/resume regression -- bisected to a mystery merge commit

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

Message-ID: <20091002223412.GA8517@mit.edu>
Date:	Fri, 2 Oct 2009 18:34:12 -0400
From:	Theodore Tso <tytso@....edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	John Stultz <johnstul@...ibm.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, tglx@...utronix.de,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ondrej Zary <linux@...nbow-software.org>,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: T400 suspend/resume regression -- bisected to a mystery merge
	commit

On Thu, Oct 01, 2009 at 06:21:50PM -0700, Linus Torvalds wrote:
> I think the revert is the right thing to do, especially as that 
> 'clocksource_mutex' looks totally bogus. Either the thing is protected by 
> 'stop_machine' or it's not. In neither case does it seem to make any sense 
> to replace a spinlock with a mutex. 
> 
> And resuming anything with a big mutex is crazy anyway. 
> 
> That said, I do wonder if this is already fixed. See commit 
> 89133f93508137231251543d1732da638e6022e1:
> 
>     clocksource: Resume clocksource without taking the clocksource mutex
> 
> which already undid the part that probably mattered for you. That said, I 
> still do think that that mutex is dubious, so maybe we should undo it all.

Hmm, I just tried the latest git release, and the problem does seem to
have disappeared.  I don't know if it was fixed by commit #89133f9,
but I'll take it.  :-)

(Note!  The problem I was bisecting is different and distinct from BZ
#14222.  First of all, for me 2.6.31 works fine, and in #14222 the
reporter claimed that 2.6.30 worked, and 2.6.31 didn't.  For me this
regression happened *after* the merge window opened.  Secondly, in
#14222 the failure reported was an OOPS, whereas in my case, the
system simply doesn't come back after the second suspend-to-memory.
The HD disk flashes once or twice, but then the machine stays dead,
with the screen not coming to life and the suspend light still lit.
Finally, I bisected the failure to a different commit (75c5158) which
is post 2.6.31, where as commit c7121843 which is pre-2.6.31.)

   		      	 		       - Ted

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