linux-kernel - Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

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: <20140514161331.GA18032@roeck-us.net>
Date:	Wed, 14 May 2014 09:13:31 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Michael Stickel <ms@...able.de>,
	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Rob Herring <robherring2@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Matt Porter <matt.porter@...aro.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Alison Chaiken <Alison_Chaiken@...tor.com>,
	Dinh Nguyen <dinh.linux@...il.com>,
	Jan Lubbe <jluebbe@...net.de>,
	Alexander Sverdlin <alexander.sverdlin@....com>,
	Dirk Behme <dirk.behme@...il.com>,
	Alan Tull <delicious.quinoa@...il.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Michael Bohan <mbohan@...eaurora.org>,
	Ionut Nicu <ioan.nicu.ext@....com>,
	Michal Simek <monstr@...str.eu>,
	Matt Ranostay <mranostay@...il.com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Pete Popov <pete.popov@...sulko.com>,
	Dan Malek <dan.malek@...sulko.com>,
	Georgi Vlaev <georgi.vlaev@...sulko.com>,
	Pantelis Antoniou <panto@...oniou-consulting.com>
Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

On Wed, May 14, 2014 at 04:49:07PM +0100, Grant Likely wrote:
> On Wed, 14 May 2014 14:11:52 +0200, Michael Stickel <ms@...able.de> wrote:
> > Hi Grant,
> > 
> > Am 14.05.2014 12:08, schrieb Grant Likely:
> > > More generally I am concerned about whether or not overlays
> > > will introduce corner cases that can never be handled correctly,
> > > particularly in how multiple overlays will get handled. I want to see
> > > very clear rules on what happens when multiple overlays are applied, and
> > > then removed again. Is it possible to remove overlays out of order? If
> > > so, what are the conditions that would not be allowed?
> > 
> > Yes, it is possible that an overlay depends on another.
> > 
> > The problem is not, that an overlay is removed other overlays depend on,
> > but that nodes of an overlay may depend on the to-be-removed overlay and
> > the resulting devicetree can become inconsistent.
> 
> So what should the rule be then? It sounds to me that it should be a
> hard and fast rule for overlays to always be removed in-order. If two
> overlays are applied, and the first one needs to be removed again, then
> that forces a removal of the second. The code needs to enforce it too.
> 
> The question can be revisited if someone can find a way to validate
> overlays do not conflict.
> 
We'll need to find a way to determine if overlays are nested. Only nested
overlays must be removed in order. Otherwise the entire concept falls apart.
In our case, overlays are used for hot plugged cards. Obviously there can
and will be more than one of those cards in the system, and they can
and will be inserted and removed in any order.

Maybe a nesting level counter in each property would do it ? Or a reference
pointing to overlay specific objects / data ?

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