linux-kernel - Re: [patch 4/6] Fix SMP poweroff hangs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <47064023.7080703@rtr.ca>
Date:	Fri, 05 Oct 2007 09:46:11 -0400
From:	Mark Lord <lkml@....ca>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Brown, Len" <len.brown@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>, simon.derr@...l.net,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch 4/6] Fix SMP poweroff hangs

Eric W. Biederman wrote:
> Mark Lord <lkml@....ca> writes:
>> Comments?  Eric?
> 
> Sorry -EBUSY.
> 
> The trylock on call_lock is a recent thing (.22), added to keep panic
> from hanging.   It probably makes more sense to move bust_spinlocks(0)
> down a few lines in kernel/panic.c and to test oops_in_progress in
> smp_send_stop and make all screwy locking behavior depend on that.

I've seen this issue (to a much lessor extent) on 2.6.17 as well.
So if earlier kernels had the regular spin_lock() there (rather than trylock)
then this is still *an* issue, but not *the* issue.  And in my specific
case (only 2 CPUs), the trylock cannot be the problem here.
But with more cores it definitely could be an issue.

> As for not waiting until cpus are in their stop loop that looks easy
> enough to remedy.  I don't know if any of those is our culprit but
> it certainly looks worth cleaning up.  If you are interested in
> testing I will cook up a patch.

I suspect this one more, as there really are not many other possibilities.
One thing to try might be to just have the power_off() code do msleep(1000)
before the ACPI poweroff call.  That would give enough time for the other
core to "halt", and is easy enough to try for diagnosis purposes.

I'm off rock climbing for a week or so, but if you cook something up
in the meanwhile then I'll test it on return.

> I haven't had a chance yet to walk through the other possible x86
> sysdev devices to see if there are any other canidates.

Cheers!

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