linux-kernel - Re: [PATCH v4 1/9] driver core: add a faux bus for use when a simple device/bus is needed

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: <D7PQHGGX4WPC.26F52356ISZU8@gmail.com>
Date: Tue, 11 Feb 2025 10:49:34 -0500
From: "Kurt Borja" <kuurtb@...il.com>
To: "Zijun Hu" <zijun_hu@...oud.com>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, <linux-kernel@...r.kernel.org>, "Lyude Paul"
 <lyude@...hat.com>, "Rafael J. Wysocki" <rafael@...nel.org>, "Danilo
 Krummrich" <dakr@...nel.org>
Cc: "Alexander Lobakin" <aleksander.lobakin@...el.com>, "Andy Shevchenko"
 <andriy.shevchenko@...ux.intel.com>, "Bjorn Helgaas" <bhelgaas@...gle.com>,
 "Jonathan Cameron" <Jonathan.Cameron@...wei.com>, "Liam Girdwood"
 <lgirdwood@...il.com>, "Lukas Wunner" <lukas@...ner.de>, "Mark Brown"
 <broonie@...nel.org>, Maíra Canal <mairacanal@...eup.net>,
 "Robin Murphy" <robin.murphy@....com>, "Simona Vetter"
 <simona.vetter@...ll.ch>, "Zijun Hu" <quic_zijuhu@...cinc.com>,
 <linux-usb@...r.kernel.org>, <rust-for-linux@...r.kernel.org>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Subject: Re: [PATCH v4 1/9] driver core: add a faux bus for use when a
 simple device/bus is needed

On Tue Feb 11, 2025 at 10:29 AM -05, Zijun Hu wrote:
> On 2025/2/10 22:29, Kurt Borja wrote:
>>> +
>>> +	ret = device_add(dev);
>>> +	if (ret) {
>>> +		pr_err("%s: device_add for faux device '%s' failed with %d\n",
>>> +		       __func__, name, ret);
>>> +		put_device(dev);
>>> +		return NULL;
>>> +	}
>> Now that the probe is synchronous, what do you think about returning
>> -ENODEV if the device failed to bind to the driver?
>> 
>
> Result of device registering @ret is not, should not be, effected by
> "device binding driver (probe result)"
>
> if device binging driver failed, you may return -ENODEV in
> faux_ops->probe(). not here.

After thinking about this discussion, I understand why this might be the
expected behavior. I'm thinking about very simple modules that would
remain loaded even if the probe fails. But of course this may cause
problems to other modules.

In the end, this is just my opinion so it would be up to Greg to decide.
However, there is still an issue with the groups added to the device,
which a user might expect they are tied to an "attached" device
lifetime and this currently not the case.

>
>> This would be useful for modules that may want to unload if the probe
>> fails.
>
> may need to root cause if probe failure happens.
>
> how to unload module automatically if probe() failure ?

If we check for !dev->driver, a module might propagate an error to the
module_init, thus making it fail to load.

-- 
 ~ Kurt