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 14:11:29 +0000
From:   Benjamin GAIGNARD <benjamin.gaignard@...com>
To:     Thomas Gleixner <tglx@...utronix.de>
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 10/14/19 3:40 PM, Thomas Gleixner wrote:
> 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.

Since CPUs won't go in deep idle I don't want to get a broadcast timer

but only an hrtimer to get accure latencies for the scheduler.

When arch arm timer doesn't set CLOCK_EVT_FEAT_C3STOP flag, my system

got a hrtimer and everything goes well. If arch arm timer set 
CLOCK_EVT_FEAT_C3STOP

hrtimer disappear (except if I add an additional broadcast timer).

What is the link between tick broadcast timer and hrtimer ? Does arch 
arm timer could only

implement them at the same time ?

Benjamin

>
> Thanks,
>
> 	tglx
>