Message-ID: <f5ea7e17-5550-4658-8f4c-1c51827c7627@icloud.com>
Date: Tue, 3 Dec 2024 22:56:54 +0800
From: Zijun Hu <zijun_hu@...oud.com>
To: Thomas Weißschuh <thomas@...ch.de>,
 James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Uwe Kleine-König <ukleinek@...nel.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Chun-Kuang Hu <chunkuang.hu@...nel.org>,
 Philipp Zabel <p.zabel@...gutronix.de>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Jean Delvare <jdelvare@...e.com>, Guenter Roeck <linux@...ck-us.net>,
 Martin Tuma <martin.tuma@...iteqautomotive.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Andreas Noever <andreas.noever@...il.com>,
 Michael Jamet <michael.jamet@...el.com>,
 Mika Westerberg <mika.westerberg@...ux.intel.com>,
 Yehezkel Bernat <YehezkelShB@...il.com>,
 Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski
 <brgl@...ev.pl>, Andrew Lunn <andrew@...n.ch>,
 Vladimir Oltean <olteanv@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, Dan Williams <dan.j.williams@...el.com>,
 Vishal Verma <vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>,
 Ira Weiny <ira.weiny@...el.com>, Takashi Sakamoto <o-takashi@...amocchi.jp>,
 Jiri Slaby <jirislaby@...nel.org>,
 Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
 Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Lee Duncan <lduncan@...e.com>, Chris Leech <cleech@...hat.com>,
 Mike Christie <michael.christie@...cle.com>,
 "Martin K. Petersen" <martin.petersen@...cle.com>,
 Nilesh Javali <njavali@...vell.com>,
 Manish Rangankar <mrangankar@...vell.com>,
 GR-QLogic-Storage-Upstream@...vell.com, Davidlohr Bueso <dave@...olabs.net>,
 Jonathan Cameron <jonathan.cameron@...wei.com>,
 Alison Schofield <alison.schofield@...el.com>,
 Andreas Larsson <andreas@...sler.com>, Stuart Yoder <stuyoder@...il.com>,
 Laurentiu Tudor <laurentiu.tudor@....com>, Jens Axboe <axboe@...nel.dk>,
 Sudeep Holla <sudeep.holla@....com>,
 Cristian Marussi <cristian.marussi@....com>, Ard Biesheuvel
 <ardb@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
 Mathieu Poirier <mathieu.poirier@...aro.org>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linux-mediatek@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-hwmon@...r.kernel.org,
 linux-media@...r.kernel.org, linux-usb@...r.kernel.org,
 linux-gpio@...r.kernel.org, netdev@...r.kernel.org,
 linux-pwm@...r.kernel.org, nvdimm@...ts.linux.dev,
 linux1394-devel@...ts.sourceforge.net, linux-serial@...r.kernel.org,
 linux-sound@...r.kernel.org, open-iscsi@...glegroups.com,
 linux-scsi@...r.kernel.org, linux-cxl@...r.kernel.org,
 sparclinux@...r.kernel.org, linux-block@...r.kernel.org,
 arm-scmi@...r.kernel.org, linux-efi@...r.kernel.org,
 linux-remoteproc@...r.kernel.org, Zijun Hu <quic_zijuhu@...cinc.com>
Subject: Re: [PATCH v2 00/32] driver core: Constify API device_find_child()
 and adapt for various existing usages

On 2024/12/3 22:07, Thomas Weißschuh wrote:
> On 2024-12-03 08:58:26-0500, James Bottomley wrote:
>> On Tue, 2024-12-03 at 21:02 +0800, Zijun Hu wrote:
>>> On 2024/12/3 20:41, Greg Kroah-Hartman wrote:
>>>> On Tue, Dec 03, 2024 at 08:23:45PM +0800, Zijun Hu wrote:
>> [...]
>>>>> or squash such patch series into a single patch ?
>>>>>
>>>>> various subsystem maintainers may not like squashing way.
>>>>
>>>> Agreed, so look into either doing it in a bisectable way if at all
>>>> possible.  As I don't see a full series here, I can't suggest how
>>>> it needs to happen :(
>>>>
>>>
>>> let me send you a full series later and discuss how to solve this
>>> issue.
>>
>> It's only slightly more complex than what we normally do: modify all
>> instances and then change the API.  In this case you have an additional
>> problem because the prototype "const void *" will cause a mismatch if a
>> function has "void *".  The easiest way to solve this is probably to
>> make device_find_child a macro that coerces its function argument to
>> having a non const "void *" and then passes off to the real function. 
>> If you do that in the first patch, then you can constify all the
>> consumers and finally remove the macro coercion in the last patch.
> 
> Casting function pointers like that should be detected and trapped by
> control flow integrity checking (KCFI).
> 
> Another possibility would be to use a macro and _Generic to dispatch to
> two different backing functions. See __BIN_ATTR() in
> include/linux/sysfs.h for an inspiration.

this way may fix building error issue but does not achieve our purpose.
our purpose is that there are only constified device_find_child().


> This also enables an incremental migration.
> 
> 

change the API prototype from:
device_find_child(..., void *data_0, int (*match)(struct device *dev,
void *data));

to:
device_find_child(..., const void *data_0, int (*match)(struct device
*dev, const void *data));

For @data_0,  void * -> const void * is okay.
but for @match, the problem is function pointer type incompatibility.

there are two solutions base on discussions.

1) squashing likewise Greg mentioned.
   Do all of the "prep work" first, and then
   do the const change at the very end, all at once.

2)  as changing platform_driver's remove() prototype.
Commit: e70140ba0d2b ("Get rid of 'remove_new' relic from platform
driver struct")

 introduce extra device_find_child_new() which is constified  -> use
*_new() replace ALL device_find_child() instances one by one ->  remove
device_find_child() -> rename *_new() to device_find_child() once.

> Thomas

Powered by blists - more mailing lists