linux-kernel - Re: [PATCH] tick/broadcast-hrtimer : Fix suspicious RCU usage in idle loop

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: <20150317072451.GO2896@worktop.programming.kicks-ass.net>
Date:	Tue, 17 Mar 2015 08:24:51 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
Cc:	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] tick/broadcast-hrtimer : Fix suspicious RCU usage in
 idle loop

On Tue, Mar 17, 2015 at 09:49:45AM +0530, Preeti U Murthy wrote:
> Ok I see your point now. Sorry about having misinterpreted it
> previously. ce_broadcast_hrtimer is not the per-cpu clock device. It is
> not a real clock device. It is a pseudo clock device, which is called
> only from the guts of the broadcast framework.
> When it is programmed, it queues a hrtimer and programs the per-cpu
> clock device. in the fashion mentioned above.
> 
> No hrtimer programming/starting/canceling will get routed through
> bc_set_next(). The broadcast framework makes use of a separate broadcast
> clock device, which is never the per-cpu clock device to wake cpus from
> idle. This device is programmed explicitly when required and not
> indirectly via timer queueing. *Only* when this broadcast clock device
> needs to reprogrammed, bc_set_next() gets called on those archs which
> *do not have a real broadcast clock device*. And the whole thing kicks
> in when cpus go idle only, not just for PowerPC but for ARM as well.

Ah, I see, tick_check_new_device() will never select it.

CLOCK_EVT_FEAT_PERCPU seems a rather pointless thing though, maybe a
remnant of something gone.

OK now it makes sense.. some of this could use a few comments, but I
suppose that's true of most things ;-)
--
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/