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: <CAKohpokEV7EatQROgzQBWPRPFEn8OsMo5EHa+q1FMwBESwiU3w@mail.gmail.com>
Date:	Fri, 20 Feb 2015 19:28:36 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
	Kevin Hilman <khilman@...aro.org>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Linaro Networking <linaro-networking@...aro.org>,
	Steven Miao <realmz6@...il.com>,
	Mark Salter <msalter@...hat.com>,
	Michal Simek <monstr@...str.eu>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Ley Foon Tan <lftan@...era.com>,
	Jonas Bonn <jonas@...thpole.se>,
	"David S. Miller" <davem@...emloft.net>,
	Jeff Dike <jdike@...toit.com>,
	Guan Xuetao <gxt@...c.pku.edu.cn>
Subject: Re: [PATCH] clockevents: Add (missing) default case for switch blocks

On 20 February 2015 at 18:52, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Viresh Kumar <viresh.kumar@...aro.org> wrote:
>> +       CLOCK_EVT_DEV_MODE_UNUSED = 0,
>
> What is 'unused' - not initialized yet?

Unused. Initially all clockevent devices are supposed to be in this
mode but later if another device replaces an existing one, the existing
one is put into this mode.

>> +       CLOCK_EVT_DEV_MODE_SHUTDOWN,
>> +       CLOCK_EVT_DEV_MODE_PERIODIC,
>> +       CLOCK_EVT_DEV_MODE_ONESHOT,
>> +       CLOCK_EVT_DEV_MODE_RESUME,
>
> What is 'resume' mode?

Introduced with: 18de5bc4c1f1 ("clockevents: fix resume logic") and is only
called during system resume to resume the clockevent devices before resuming
the tick. Only few implementations do meaningful stuff here.

>> +       CLOCK_EVT_DEV_MODE_ONESHOT_STOPPED,  /* This would be the new
>> mode which I will add later */
>
> What does this mode express?

I have added it here to show how things would look like eventually,
but it wouldn't
be present in the patch which splits the enum into two parts..

Its only important for NOHZ_FULL (IDLE ? Maybe). When we decide that the tick
(LOWRES) or hrtimer interrupt (HIGHRES) isn't required for indefinite
period of time
(i.e. no timers/hrtimers are present to serve), we skip reprogramming
the clockevent
device. But its already reprogrammed from the tick-handler and so will
fire atleast
once again.

The case is worst for implementations where the underlying hardware doesn't have
support for ONESHOT mode. And so they emulate ONESHOT over PERIODIC.
And in those cases, these spurious interrupts come at a rate last programmed for
the clockevent device. And that is mostly tick-rate..

> So for state machines it's important to document the states
> and the transitions between them very clearly - please
> start with that.

Sure.

> Also, this should not be in a generic header, it should be
> somewhere internal in kernel/time/.

Right. But there are some excellent drivers which are comparing things against
dev->mode (i.e. enum clock_event_dev_mode now..). I need to fix them as well
first to push this into some internal header.

>> Ofcourse, we also need to replace 'clock_event_mode' with
>> 'clock_event_dev_mode' and 'CLOCK_EVT_MODE_*' with
>> 'CLOCK_EVT_DEV_MODE_*' in all core code..
>
> Yes.

Thanks for your suggestions.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ