[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqL9OnGQ5WVHSQPCTEUKLk_fSTgZ0qnPjzqQqW9SZ5hURg@mail.gmail.com>
Date: Mon, 4 Dec 2017 20:25:57 -0600
From: Rob Herring <robh+dt@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
Frank Rowand <frowand.list@...il.com>,
Colin King <colin.king@...onical.com>,
Dan Carpenter <dan.carpenter@...cle.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] of: overlay: Fix cleanup order in of_overlay_apply()
On Mon, Dec 4, 2017 at 1:45 PM, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> Hi Rob,
>
> On Mon, Dec 4, 2017 at 8:35 PM, Rob Herring <robh+dt@...nel.org> wrote:
>> On Mon, Dec 4, 2017 at 9:47 AM, Geert Uytterhoeven
>> <geert+renesas@...der.be> wrote:
>>> The special overlay mutex is taken first, hence it should be released
>>> last in the error path.
>>>
>>> Move "mutex_lock(&of_mutex)" up, as suggested by Frank, as
>>> free_overlay_changeset() should be called with that mutex held if any
>>> non-trivial cleanup is to be done.
>>
>> Not holding the of_mutex for of_resolve_phandles is just wrong.
>> Without it, a node and new phandle could be added via of_attach_node
>> making the max phandle wrong.
>
> After my patch it's held, so what's the problem?
There's no problem. Just highlighting the issue with the prior
location is more than it seems from your explanation.
Rob
Powered by blists - more mailing lists