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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <664185f4-b87a-4635-9ee9-2f0e7494195a@huawei.com>
Date: Tue, 11 Feb 2025 19:26:18 +0800
From: "zhangzekun (A)" <zhangzekun11@...wei.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
CC: Oleksij Rempel <o.rempel@...gutronix.de>, <robh@...nel.org>,
	<saravanak@...gle.com>, <justin.chen@...adcom.com>,
	<florian.fainelli@...adcom.com>, <andrew+netdev@...n.ch>, <kuba@...nel.org>,
	<kory.maincent@...tlin.com>, <jacopo+renesas@...ndi.org>,
	<kieran.bingham+renesas@...asonboard.com>, <maddy@...ux.ibm.com>,
	<mpe@...erman.id.au>, <npiggin@...il.com>, <olteanv@...il.com>,
	<davem@...emloft.net>, <taras.chornyi@...ision.eu>, <edumazet@...gle.com>,
	<pabeni@...hat.com>, <sudeep.holla@....com>, <cristian.marussi@....com>,
	<arm-scmi@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
	<linux-media@...r.kernel.org>, <netdev@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <chenjun102@...wei.com>
Subject: Re: [PATCH 1/9] of: Add warpper function
 of_find_node_by_name_balanced()



在 2025/2/10 18:03, Laurent Pinchart 写道:
> Hi Zekun,
> 
> On Mon, Feb 10, 2025 at 02:47:28PM +0800, zhangzekun (A) wrote:
>>> I think we all agree that of_find_node_by_name() is miused, and that it
>>> shows the API isn't optimal. What we have different opinions on is how
>>> to make the API less error-prone. I think adding a new
>>> of_find_node_by_name_balanced() function works around the issue and
>>> doesn't improve the situation much, I would argue it makes things even
>>> more confusing.
>>>
>>> We have only 20 calls to of_find_node_by_name() with a non-NULL first
>>> argument in v6.14-rc1:
>>>
>>> arch/powerpc/platforms/chrp/pci.c:      rtas = of_find_node_by_name (root, "rtas");
>>>
>>> The 'root' variable here is the result of a call to
>>> 'of_find_node_by_path("/")', so I think we could pass a null pointer
>>> instead to simplify things.
>>>
>>> arch/powerpc/platforms/powermac/pic.c:          slave = of_find_node_by_name(master, "mac-io");
>>>
>>> Here I believe of_find_node_by_name() is called to find a *child* node
>>> of 'master'. of_find_node_by_name() is the wrong function for that.
>>>
>>> arch/sparc/kernel/leon_kernel.c:        np = of_find_node_by_name(rootnp, "GAISLER_IRQMP");
>>> arch/sparc/kernel/leon_kernel.c:                np = of_find_node_by_name(rootnp, "01_00d");
>>> arch/sparc/kernel/leon_kernel.c:        np = of_find_node_by_name(nnp, "GAISLER_GPTIMER");
>>> arch/sparc/kernel/leon_kernel.c:                np = of_find_node_by_name(nnp, "01_011");
>>>
>>> Here too the code seems to be looking for child nodes only (but I
>>> couldn't find a DT example or binding in-tree, so I'm not entirely
>>> sure).
>>>
>>> drivers/clk/ti/clk.c:   return of_find_node_by_name(from, tmp);
>>>
>>> Usage here seems correct, the reference-count decrement is intended.
>>>
>>> drivers/media/i2c/max9286.c:    i2c_mux = of_find_node_by_name(dev->of_node, "i2c-mux");
>>> drivers/media/platform/qcom/venus/core.c:       enp = of_find_node_by_name(dev->of_node, node_name);
>>> drivers/net/dsa/bcm_sf2.c:      ports = of_find_node_by_name(dn, "ports");
>>> drivers/net/dsa/hirschmann/hellcreek_ptp.c:     leds = of_find_node_by_name(hellcreek->dev->of_node, "leds");
>>> drivers/net/ethernet/broadcom/asp2/bcmasp.c:    ports_node = of_find_node_by_name(dev->of_node, "ethernet-ports");
>>> drivers/net/ethernet/marvell/prestera/prestera_main.c:  ports = of_find_node_by_name(sw->np, "ports");
>>> drivers/net/pse-pd/tps23881.c:  channels_node = of_find_node_by_name(priv->np, "channels");
>>> drivers/regulator/scmi-regulator.c:     np = of_find_node_by_name(handle->dev->of_node, "regulators");
>>> drivers/regulator/tps6594-regulator.c:          np = of_find_node_by_name(tps->dev->of_node, multi_regs[multi].supply_name);
>>>
>>> Incorrect usage, as far as I understand all those drivers are looking
>>> for child nodes only.
>>>
>>> drivers/of/unittest.c:          found = of_find_node_by_name(nd->overlay, "test-unittest16");
>>> drivers/of/unittest.c:          found = of_find_node_by_name(nd->overlay, "test-unittest17");
>>> drivers/of/unittest.c:          found = of_find_node_by_name(nd->overlay, "test-unittest18");
>>> drivers/of/unittest.c:          found = of_find_node_by_name(nd->overlay, "test-unittest19");
>>>
>>> Here too I think only child nodes are meant to be considered.
>>>
>>> of_find_node_by_name() is very much misused as most callers want to find
>>> child nodes, while of_find_node_by_name() will walk the whole DT from a
>>> given starting point.
>>>
>>> I think the right fix here is to
>>>
>>> - Replace of_find_node_by_name(root, ...) with
>>>     of_find_node_by_name(NULL, ...) in arch/powerpc/platforms/chrp/pci.c
>>>     (if my understanding of the code is correct).
>>
>> For arch/powerpc/platforms/chrp/pci.c, noticing that there is a comment
>> in setup_peg2():
>>    /* keep the reference to the root node */
>>
>> It might can not be convert to of_find_node_by_name(NULL, ...), and the
>> origin use of of_find_node_by_name() put the ref count which want to be
>> kept.
> 
> But the reference is dropped by of_find_node_by_name(). Unless I'm
> missing something, dropping the lien
> 
> 	struct device_node *root = of_find_node_by_path("/");
> 
> and changing
> 
> 	rtas = of_find_node_by_name (root, "rtas");
> 
> to
> 
> 	rtas = of_find_node_by_name (NULL, "rtas");
> 
> will not change the behaviour of the code.
> 

Hi, Laurent,

I think that the original code try to keep the refcount get by 
of_find_node_by_path(), but leak it accidently by 
of_find_node_by_name(). I am not sure that what driver really wants to 
do and if it has a bug here.

Beset Regards,
Zekun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ