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: <Zrp89mKNvTn+PdmG@hu-bjorande-lv.qualcomm.com>
Date: Mon, 12 Aug 2024 14:21:58 -0700
From: Bjorn Andersson <quic_bjorande@...cinc.com>
To: Rob Herring <robh@...nel.org>
CC: Bjorn Andersson <andersson@...nel.org>,
        Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        "Conor Dooley" <conor+dt@...nel.org>, Felipe Balbi <balbi@...nel.org>,
        Wesley
 Cheng <quic_wcheng@...cinc.com>,
        Saravana Kannan <saravanak@...gle.com>,
        "Thinh Nguyen" <Thinh.Nguyen@...opsys.com>,
        Philipp Zabel
	<p.zabel@...gutronix.de>,
        Konrad Dybcio <konrad.dybcio@...aro.org>, <linux-usb@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 3/7] of: dynamic: Don't discard children upon node
 attach

On Mon, Aug 12, 2024 at 02:24:21PM -0600, Rob Herring wrote:
> On Sun, Aug 11, 2024 at 9:07 PM Bjorn Andersson <andersson@...nel.org> wrote:
> >
> > From: Bjorn Andersson <quic_bjorande@...cinc.com>
> >
> > When dynamically modifying DeviceTree it's useful to be able to reparent
> > nodes, but of_attach_node() clear the child pointer and hence discards
> > any child nodes.
> 
> of_attach_node() is kind of the legacy API. You should be using
> changeset API. But I guess you really mean __of_attach_node() here
> which both use.
> 

I failed to spot the changeset part of the API, that does indeed look
like a more robust solution. I will look into this, thanks.

> > Retain the child pointer upon attach, so that the client code doesn't
> > need to manually rebuild the tree.
> >
> > Current users of of_attach_node() either avoids attaching nodes with
> > children or explicitly attaches nodes without children, so no impact is
> > expected to current users.
> >
> > Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> > ---
> >  drivers/of/dynamic.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> > index 110104a936d9..32e1dffd9f96 100644
> > --- a/drivers/of/dynamic.c
> > +++ b/drivers/of/dynamic.c
> > @@ -221,7 +221,6 @@ static void __of_attach_node(struct device_node *np)
> >                         np->phandle = 0;
> >         }
> >
> > -       np->child = NULL;
> >         np->sibling = np->parent->child;
> >         np->parent->child = np;
> >         of_node_clear_flag(np, OF_DETACHED);
> 
> Before OF_DETACHED had a clear meaning. Now, are child nodes detached
> or not?

As far as I understood, the detached node will have children and as I
re-attach it, those children will just be leaked. The current (few)
clients are then making sure not to detach nodes with cihldren.

Perhaps the expectation is that the client will have traversed and
detached the children, and will then reattach them here?

Or perhaps the intention was to never allow detaching and reattaching a
node with children?

> If it means not attached to the root tree, then it is
> redundant having it per node. If it means parent and sibling aren't
> set, then what's the point as we can just check for NULL ptrs.
> 

In practice, my goal is to detach the "ports" node from one parent and
attach it to another node, without breaking the graph.

In patch 6 this is used as:

  of_node_detach(child);
  child->parent = new;
  of_node_attach(child);

> This all seems fragile on top of what's already fragile.
> 

No concerns with that statement, I will start investigate the changeset
API.

I appreciate any guidance related to reparenting my graph node.

> Rob

Thank you,
Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ