[1/3] powerpc/pmac: Fix DT refcount imbalance in pmac_pic_probe_oldstyle

of_find_node_by_name() calls of_node_put() on its "from" parameter,
which must not be done on "master", as it's still in use, and will be
released manually later.  This may cause a zero kref refcount.
Use of_get_child_by_name() instead to fix this.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: linuxppc-dev@lists.ozlabs.org
---
Compile-tested only
---
 arch/powerpc/platforms/powermac/pic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Wed, 2015-14-01 at 13:51:57 UTC, Geert Uytterhoeven wrote:
> of_find_node_by_name() calls of_node_put() on its "from" parameter,
> which must not be done on "master", as it's still in use, and will be
> released manually later.  This may cause a zero kref refcount.
> Use of_get_child_by_name() instead to fix this.

But of_find_node_by_name() searches *all* nodes, not just the children of the
parameter.

So this is a logic change AFAICS, and I have no idea what machines we'd need to
test on to check it.

So I think an of_node_get(master) would be safer and also fix the refcounting.

cheers

Hi Michael,

On Fri, Jan 30, 2015 at 5:09 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> On Wed, 2015-14-01 at 13:51:57 UTC, Geert Uytterhoeven wrote:
>> of_find_node_by_name() calls of_node_put() on its "from" parameter,
>> which must not be done on "master", as it's still in use, and will be
>> released manually later.  This may cause a zero kref refcount.
>> Use of_get_child_by_name() instead to fix this.
>
> But of_find_node_by_name() searches *all* nodes, not just the children of the
> parameter.

That's correct. However, I guess the second mac-io will just be a direct child.

> So this is a logic change AFAICS, and I have no idea what machines we'd need to
> test on to check it.

Originally it comes from arch/ppc/platforms/pmac_pic.c, added in 2002 in
full-history-linux commit 5ea3254844ae344a
("Import arch/ppc and include/asm-ppc changes from linuxppc_2_5 tree").

I've also checked my linuxppc mail archives from 1997-2002, but couldn't find
the actual patch and a description.

So I don't know on which machines it's needed.

> So I think an of_node_get(master) would be safer and also fix the refcounting.

If no one can confirm the above, that may indeed be the best solution.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Fri, 2015-01-30 at 10:00 +0100, Geert Uytterhoeven wrote:
> Hi Michael,
> 
> On Fri, Jan 30, 2015 at 5:09 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> > On Wed, 2015-14-01 at 13:51:57 UTC, Geert Uytterhoeven wrote:
> >> of_find_node_by_name() calls of_node_put() on its "from" parameter,
> >> which must not be done on "master", as it's still in use, and will be
> >> released manually later.  This may cause a zero kref refcount.
> >> Use of_get_child_by_name() instead to fix this.
> >
> > But of_find_node_by_name() searches *all* nodes, not just the children of the
> > parameter.
> 
> That's correct. However, I guess the second mac-io will just be a direct child.

Yeah OK, I don't have a system or an example device tree to check.

> > So this is a logic change AFAICS, and I have no idea what machines we'd need to
> > test on to check it.
> 
> Originally it comes from arch/ppc/platforms/pmac_pic.c, added in 2002 in
> full-history-linux commit 5ea3254844ae344a
> ("Import arch/ppc and include/asm-ppc changes from linuxppc_2_5 tree").
> 
> I've also checked my linuxppc mail archives from 1997-2002, but couldn't find
> the actual patch and a description.
> 
> So I don't know on which machines it's needed.

Yep. Ben or Paul might know, but even then their memory may not be perfect :)
 
> > So I think an of_node_get(master) would be safer and also fix the refcounting.
> 
> If no one can confirm the above, that may indeed be the best solution.

I think so. Given how few of these machines are around it's easy to break them
with an inadvertent change like this, so I think it's better to be safe.

Wanna send a patch for that?

cheers