linux-kernel - Re: Locking in the clk API

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:	Tue, 11 Jan 2011 12:15:52 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Jeremy Kerr <jeremy.kerr@...onical.com>
Cc:	linux-sh@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Uwe Kleine-K??nig <u.kleine-koenig@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>
Subject: Re: Locking in the clk API

On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> * clk_enable: may sleep
> 
> * clk_disable: may not sleep, but it's possible to make the global
>   clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
>   non-atomic context.
> 
> * clk_get_rate: may not sleep
> 
> * clk_set_rate: may sleep
> 
> As we build up our requirements, we can adjust as suitable.
> 
This looks like a complete disaster, and is also completely inconsistent
with how the API is being used by the vast majority of users today. You
have an API that can or can not sleep with no indication as to which is
which based off of the API naming, which is just asking for trouble.

As it is today, most users expect that these are all usable from atomic
context, and as far as I can tell the only special case you have are for
some crap busses with insane latencies. In this case you should simply
pile on _cansleep() versions of the API and make it apparent that those
drivers are the special cases, not the other way around.

Having half of the API sleepable and the other not with no indication of
which is which simply makes it completely unusable and error prone for
both atomic and non-atomic contexts.
--
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/