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 09:28:42 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-sh@...r.kernel.org,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	linux-kernel@...r.kernel.org, Paul Mundt <lethal@...ux-sh.org>,
	Uwe Kleine-K??nig <u.kleine-koenig@...gutronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: Locking in the clk API

On Tue, Jan 11, 2011 at 10:03:11AM +0100, Sascha Hauer wrote:
> Quoting Russell:
> 
> > I hate the GPIO APIs for doing this _cansleep crap as the decision of
> > whether to use the _cansleep or normal APIs normally can't be made at
> > the time when the API is used, but sometime later.  Many people just use
> > the non-_cansleep versions irrespective of the context they're in -
> > which is unnecessarily restrictive - consider what happens if you then
> > have that driver use a GPIO on an I2C peripheral...
> 
> Sounds like we should rather have s sleeping clk_enable and a
> clk_enable_atomic. This way people can use standard clk_enable until
> a 'scheduling while atomic' gives a hint in the right direction.

Well, there's a problem lurking here - lets take the PL011 driver.  You
convert the console write calls to use clk_enable_atomic(), leaving the
rest.

The driver will appear to work fine with a sleeping clk, until you get
a console write.  Maybe your SoC developer never tried the console on
the particular port you just tried to use?  Maybe such a driver should
use the _atomic() versions throughout?

Another solution occurs to me: clk_enable() which returns -EAGAIN if
it's called in an atomic context but needs to sleep, and let the driver
deal with the clock not being enabled when it wants it.  The down side
is it requires the driver to have additional code to sort out such a
problem.

Maybe another approach for the time being is to unify in two steps: first
unify the implementations which use a spinlock - and those which can use
a spinlock, and separately those which must use a mutex.

Then this issue can be revisited in the future.
--
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/