linux-kernel - Re: [RFC 00/17] clk: Add per-controller locks to fix deadlocks

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: <65703100-1e16-6c34-babe-40e630180688@samsung.com>
Date:	Tue, 16 Aug 2016 15:51:10 +0200
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Lee Jones <lee@...nel.org>, Eric Anholt <eric@...olt.net>,
	Florian Fainelli <f.fainelli@...il.com>,
	Ray Jui <rjui@...adcom.com>,
	Scott Branden <sbranden@...adcom.com>,
	bcm-kernel-feedback-list@...adcom.com,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Kukjin Kim <kgene@...nel.org>,
	Russell King <linux@...linux.org.uk>,
	Mark Brown <broonie@...nel.org>, linux-clk@...r.kernel.org,
	linux-rpi-kernel@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-samsung-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
	alsa-devel@...a-project.org
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
	Javier Martinez Canillas <javier@....samsung.com>,
	a.hajda@...sung.com,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [RFC 00/17] clk: Add per-controller locks to fix deadlocks

On 08/16/2016 03:34 PM, Krzysztof Kozlowski wrote:
> Hi,
> 
> RFC, please, do not apply, maybe except patch #1 which is harmless.
> 
> 
> Introduction
> ============
> The patchset brings new entity: clock controller representing a hardware
> block.  The clock controller comes with its own prepare lock which
> is used then in many places.  The idea is to fix the deadlock mentioned
> in commit 10ff4c5239a1 ("i2c: exynos5: Fix possible ABBA deadlock by keeping
> I2C clock prepared") and commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA deadlock
> by keeping clock prepared").
> 

Damn, I forgot to describe the overall idea. :) It is mentioned in patch
15 but probably not many will have enough of patience to reach it.

The locking idea
================
Clock controllers representing different hardware blocks, will contain
its own prepare lock which protects the clocks inside controller.  The
hierarchy itself is protected by global lock.

In prepare path, the global prepare lock is removed.  This is direct
solution for the deadlock.

Clock hierarchy imposes also hierarchy between controllers so when a
prepare happens, also parents have to be locked.

Following locking design was chosen:
1. For prepare/unprepare paths: lock only clock controller and its
   parents.
2. For recalc rates paths: lock global lock, the controller and its
   children.
3. For reparent paths: lock entire tree up down (children and parents)
   and the global lock as well.

In each case of traversing the clock hierarchy, the locking of
controllers is always from children to parents.

Best regards,
Krzysztof