linux-kernel - Re: [PATCH 2/5] driver core: Introduce an API constify_device_find_child

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: <3f7e9969-5285-4dba-b16e-65c6b10ee89a@quicinc.com>
Date: Tue, 13 Aug 2024 18:50:04 +0800
From: quic_zijuhu <quic_zijuhu@...cinc.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Zijun Hu
	<zijun_hu@...oud.com>
CC: "Rafael J. Wysocki" <rafael@...nel.org>,
        Davidlohr Bueso
	<dave@...olabs.net>,
        Jonathan Cameron <jonathan.cameron@...wei.com>,
        Dave
 Jiang <dave.jiang@...el.com>,
        Alison Schofield <alison.schofield@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Dan
 Williams <dan.j.williams@...el.com>,
        Takashi Sakamoto
	<o-takashi@...amocchi.jp>,
        Timur Tabi <timur@...nel.org>,
        "David S. Miller"
	<davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, <linux-kernel@...r.kernel.org>,
        <linux-cxl@...r.kernel.org>, <linux1394-devel@...ts.sourceforge.net>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/5] driver core: Introduce an API
 constify_device_find_child_helper()

On 8/13/2024 5:45 PM, Greg Kroah-Hartman wrote:
> On Sun, Aug 11, 2024 at 08:18:08AM +0800, Zijun Hu wrote:
>> From: Zijun Hu <quic_zijuhu@...cinc.com>
>>
>> Introduce constify_device_find_child_helper() to replace existing
>> device_find_child()'s usages whose match functions will modify
>> caller's match data.
> 
> Ick, that's not a good name, it should be "noun_verb" with the subsystem being on the prefix always.
> 
okay, got it.

is it okay to use device_find_child_mut() suggested by Przemek Kitszel ?

> But why is this even needed?  Device pointers are NOT const for the
> obvious reason that they can be changed by loads of different things.
> Trying to force them to be const is going to be hard, if not impossible.
> 

[PATCH 3/5] have more discussion about these questions with below link:
https://lore.kernel.org/all/8b8ce122-f16b-4207-b03b-f74b15756ae7@icloud.com/


The ultimate goal is to make device_find_child() have below prototype:

struct device *device_find_child(struct device *dev, const void *data,
		int (*match)(struct device *dev, const void *data));

Why ?

(1) It does not make sense, also does not need to, for such device
finding operation to modify caller's match data which is mainly
used for comparison.

(2) It will make the API's match function parameter have the same
signature as all other APIs (bus|class|driver)_find_device().


My idea is that:
use device_find_child() for READ only accessing caller's match data.

use below API if need to Modify caller's data as
constify_device_find_child_helper() does.
int device_for_each_child(struct device *dev, void *data,
                    int (*fn)(struct device *dev, void *data));

So the The ultimate goal is to protect caller's *match data* @*data  NOT
device @*dev.

> thanks,
> 
> greg k-h