linux-kernel - Re: [PATCH] clockevents: Add (missing) default case for switch blocks

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:	Fri, 20 Feb 2015 11:52:19 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Viresh Kumar <viresh.kumar@...aro.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


* Viresh Kumar <viresh.kumar@...aro.org> wrote:

> > So why is a 'default' mode needed then? It makes the 
> > addition of new modes to the legacy handler easier, 
> > which looks backwards.
> 
> The requirement was to add another mode ONESHOT_STOPPED 
> [1], to be supported only by the new per-mode callbacks..

Why would a callback need any flag, and why would a flag be 
visible to old legacy callbacks?

> We have got a clear check in core with the patch Peter 
> mentioned above, which doesn't let us call legacy 
> ->set_mode() for the newer modes.
> 
>         if (dev->set_mode) {
>                 /* Legacy callback doesn't support new modes */
>                 if (mode > CLOCK_EVT_MODE_RESUME)
>                        return -ENOSYS;
>                dev->set_mode(mode, dev);
>                return 0;
>         }

So here is where one of your problems comes from: why did 
you add CLOCK_EVT_MODE_RESUME to the interface? Phase it 
out, it's a legacy interface - new callbacks shouldn't need 
any mode flags to begin with.

> > So I'm confused: if we are using proper callbacks (like 
> > my example outlined) , why is a 'mode enum' needed at 
> > all?
> 
> The enum has two uses today:
> 
> - pass mode to the legacy ->set_mode() callback, which 
> isn't required for the new callbacks.

But this is misguided, as per above.

> - flag for clockevent core's internal state machine, 
>   which it would still require. For example, it checks 
>   new-mode != old-mode before changing the mode..

Internal state machine state should be decoupled from any 
interface flags - especially when the interface is legacy.

> I believe the enum is still required for the state 
> machine, even with new per-mode callbacks.

That needs to be fixed first then, before introducing new 
API variants.

Thanks,

	Ingo
--
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/