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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <47063EC7.4060105@rtr.ca>
Date:	Fri, 05 Oct 2007 09:40:23 -0400
From:	Mark Lord <lkml@....ca>
To:	Linux Kernel <linux-kernel@...r.kernel.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"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>
Subject: Re: [patch 4/6] Fix SMP poweroff hangs

(reposting this.. somehow left LKML off the TO/CC list)

Mark Lord wrote:
> Eric W. Biederman wrote:
>> Mark Lord <lkml@....ca> writes:
..
>> The code path on i386 should be:
>> machine_power_off
>>   native_machine_power_off
>>      machine_shutdown(); (which disables the other cpus)
>>     smp_call_function
>>        stop_this_cpu (on each cpu to be stopped.
>>      pm_power_off(); (which turns off the power)
> ..
>> This does sound like a race of some sort.
>
> Mmm... thanks for the tour.
>
> The cpu hotplug code appears to take great precautions against internal races
> (dunno if it succeeds or not, though), but the correspond code in native_smp_send_stop()
> looks a bit iffy by comparison.  I wonder if that's where it gets stuck?
>
> static void native_smp_send_stop(void)
> {
>        /* Don't deadlock on the call lock in panic */
>        int nolock = !spin_trylock(&call_lock);
>        unsigned long flags;
>
>        local_irq_save(flags);
>        __smp_call_function(stop_this_cpu, NULL, 0, 0);
>        if (!nolock)
>                spin_unlock(&call_lock);
>        disable_local_APIC();
>        local_irq_restore(flags);
> }
>
> So basically, it tries to avoid races by grabbing the call_lock,
> but then ignores that lock and proceeds anyway.  Recipe for a race?

Hmmmm.. and that code also fails to wait for the other CPU(s)
to actually halt (not sure how it could wait, but it doesn't even try),
so the other CPU(s) could easily still be active when we then stumble
into our ACPI call to turn the power off.

I suppose that might possibly hurt something.

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@...ox.com
-
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/