linux-kernel - Re: [PATCH] of: dynamic: Avoid reversing sibling order

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: <e88314d7-894c-48fd-a16e-5b32b6261bea@iinet.net.au>
Date: Fri, 3 Jan 2025 13:07:57 +1100
From: Stephen Gordon <gordoste@...et.net.au>
To: Rob Herring <robh@...nel.org>
Cc: Saravana Kannan <saravanak@...gle.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: dynamic: Avoid reversing sibling order

On 3/01/2025 3:46 am, Rob Herring wrote:

> The order should not be significant. What are the nodes where the order matters?

The devicetree spec certainly doesn't make any guarantees of node order, 
so this is a reasonable question.

The driver in question is using the of_graph_* functions with a tree like:

ports {
	p0: port@0 { reg = <0>; endpoint { }; };
	p1: port@1 { reg = <1>; endpoint { }; };
	p2: port@2 { reg = <2>; endpoint { }; };
};

The driver navigates to p0 using various graph functions, because it 
needs to process that before any other endpoint. It then uses 
of_graph_get_next_port_endpoint to iterate through the remaining 
endpoints. However, when the DT is created by dynamic.c, p0 is last and 
no further endpoints are returned.  If the tree is created by fdt.c or 
pdt.c, everything works fine, because the list of siblings is in the 
order they were specified in the file.

> If the order matters, we create yet another problem with overlays
> because if an overlay adds a child node where does it go WRT existing
> child nodes? There is no way for the overlay to express that.
> 

AFAICS, this is the only example where child nodes are not inserted at 
the end, so a different order is guaranteed when the tree is loaded by 
this code (versus fdt.c/pdt.c).

For example, code using a phandle to access the "first" child of a node 
and then calling of_get_next_child() to attempt to iterate through the 
siblings will work fine - except on trees loaded by dynamic.c.

In the end, it's up to you. If this can't be changed, then we can fairly 
easily work around it. I just thought it was worth letting you know that 
the various tree-building mechanisms behave differently in this regard.

Happy New Year!

Regards
Stephen