linux-kernel - Re: [PATCH]x86, reboot: Fix a warning message triggered by stop_other

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]

Message-ID: <20120522133356.GW32472@redhat.com>
Date:	Tue, 22 May 2012 09:33:56 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	Feng Tang <feng.tang@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>,
	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH]x86, reboot: Fix a warning message triggered by
 stop_other_cpus()

On Tue, May 22, 2012 at 10:52:33AM +0800, Feng Tang wrote:
> 
> The root cause seems to be the default_send_IPI_mask_allbutself_phys()
> takes quiet some time (I measured it could be several ms) to complete
> sending NMIs to all the other 23 CPUs, and for HZ=250/1000 system, the

I sent Ingo a patch (which he took in), that reverts this path to interrupts
again (and NMIs as a fallback if it fails).  The problem will still exist
I assume though I don't know if it changes the timing characteristics.

> time is long enough for a timer interrupt to happen, which will in
> turn trigger to kick load balance to a stopped CPU and cause this
> warning in native_smp_send_reschedule().
> 
> So disabling the local irq before stop_other_cpu() can fix this
> problem (tested 25 times reboot ok), and it is fine as there should
> be nobody caring the timer interrupt in such reboot stage.

It seems to be fine.  I just do not know enough about the load balancing
the timer interrupt does to know if this is the right way to go or not.

So from the shutdown cpu perspective, you are just blocking the interrupt
from occurring while we shutdown the other cpus, which prevents the load
balancer from running and seeing cpus disappear beneath it.  Sounds
reasonable.

Though on the other hand the same interrupt on another cpu might spit out
the same warning as cpus disappear without notification if it tries to
reschedule.  Probably rare and the window is probably small as the cpus
would probably all 'stop' rather quickly.

I don't know.  I guess it is ok.

Cheers,
Don
--
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/