linux-kernel - Re: [PATCH] tick: check if broadcast device could really be stopped

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]

Date:   Mon, 14 Oct 2019 15:40:21 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Benjamin GAIGNARD <benjamin.gaignard@...com>
cc:     "fweisbec@...il.com" <fweisbec@...il.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "marc.zyngier@....com" <marc.zyngier@....com>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>
Subject: Re: [PATCH] tick: check if broadcast device could really be
 stopped

On Mon, 14 Oct 2019, Benjamin GAIGNARD wrote:
> On 10/14/19 2:56 PM, Thomas Gleixner wrote:
> > On Wed, 9 Oct 2019, Benjamin Gaignard wrote:
> >> @@ -78,7 +78,7 @@ static bool tick_check_broadcast_device(struct clock_event_device *curdev,
> >>   {
> >>   	if ((newdev->features & CLOCK_EVT_FEAT_DUMMY) ||
> >>   	    (newdev->features & CLOCK_EVT_FEAT_PERCPU) ||
> >> -	    (newdev->features & CLOCK_EVT_FEAT_C3STOP))
> >> +	    tick_broadcast_could_stop(newdev))
> > No. This might be called _before_ a cpuidle driver is available and then
> > when that driver is loaded and goes deep, everything goes south.
> 
> What could be the solution to let know to tick broadcast framework that 
> this device
> 
> will not be stopped (because CPU won't go in idle) ?
> 
> I have tried to put "always-on" property on DT but it was a NACK too:
> 
> https://lkml.org/lkml/2019/9/27/164
> 
> Do I have miss a flag somewhere ?

I don't understand what you are trying to achieve here. If the tick device,
i.e. the comparator stops working in deep idle states, then the device has
rightfully the CLOCK_EVT_FEAT_C3STOP (mis)feature set. Which means that the
system needs a fallback device for the deep idle case. If there is no
physical fallback device then you should enable the hrtimer based broadcast
pseudo tick device.

If the CPUs never go deep idle because there is no idle driver loaded or
the deep power state in which the comparator stops working is never
reached, then the broadcast hrtimer will never be used. It just eats a bit
of memory and a few extra instructions.

Thanks,

	tglx