linux-kernel - Re: [PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20141003152244.GV5182@n2100.arm.linux.org.uk>
Date:	Fri, 3 Oct 2014 16:22:44 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Andrzej Hajda <a.hajda@...sung.com>,
	"open list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	"open list:INTEL DRM DRIVERS..." <intel-gfx@...ts.freedesktop.org>,
	Seung-Woo Kim <sw0312.kim@...sung.com>,
	open list <linux-kernel@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	"moderated list:ARM/S5P EXYNOS AR..." 
	<linux-samsung-soc@...r.kernel.org>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in
	KMS drm drivers

On Fri, Oct 03, 2014 at 01:39:21PM +0200, Daniel Vetter wrote:
> On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda <a.hajda@...sung.com> wrote:
> > But this is an issue closely connected with component framework.
> > Component framework separates master component probe and drm device
> > initialization. As a result PM ops which are synchronized with probe
> > (via device_lock)
> > are no more synchronized with drm initialization which is usually called
> > from
> > .bind callback.
> 
> Now I'm confused. component->bind and drm initialization is about
> driver load, but all this code here is about system suspend/resume
> really. So I'm rather confused what problem you actually want to fix
> ..

The component *helper* will disconnect the bind of the master device
from its probe if the components aren't already known.  If all the
components are known at the point the master device probes, the
master device lock will be held (since we'll be operating within the
master device's probe function.)

The issue here is that while the master device is being probed, the
per-device lock is held.  Beneath that lock there are locks in the
component helper which will be taken, and thus will end up depending
upon the per-device lock.

This means that we pretty much can not guarantee synchronisation between
PM on the master device and the component helper calling the bind
callback - if we tried to take the per-device lock here, we would either
deadlock, or we would end up with AB-BA lock dependencies.

What we /could/ do is expose lock/unlock functions from the component
helper so that PM implementations can synchronise with binds - or I could
look at whether we could integrate the component helper into the device
model.  I suspect the latter would not be met with enthusiasm as it would
mean adding bloat to the driver core structures, which would not be needed
in 99% of cases.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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/