[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f63f0277-4318-4a98-6ad4-157f7ef164ea@web.de>
Date: Wed, 25 Apr 2018 22:09:38 +0200
From: Jan Kiszka <jan.kiszka@....de>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Frank Rowand <frowand.list@...il.com>,
Rob Herring <robh+dt@...nel.org>, Alan Tull <atull@...nel.org>,
Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
Pantelis Antoniou <panto@...oniou-consulting.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
Jailhouse <jailhouse-dev@...glegroups.com>
Subject: Re: [PATCH v7 2/5] of: change overlay apply input data from
unflattened to FDT
On 2018-04-25 21:53, Geert Uytterhoeven wrote:
> Hi Jan,
>
> On Wed, Apr 25, 2018 at 9:40 PM, Jan Kiszka <jan.kiszka@....de> wrote:
>> What other pointers are we talking about?
>
> There's also the issue that some data has been allocated using kmalloc(),
> while others hasn't. The "other" pointers point to e.g. early bootmem or
> memblock.
Should not be an issue for overlays or of_changesets, should it?
Yes, I've learned the hard way that it is a very bad idea to build
changesets with properties that were not dynamically allocated. Maybe
that is documented somewhere, how the ownership of those objects change
after apply and how they may get handled later on. But now as I know,
it's kind of consistent and rather easy to account for.
Jan
Powered by blists - more mailing lists