From: level0000x <level_zero@qq.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>
Cc: linux-kernel@vger.kernel.org, level0000x <level_zero@qq.com>
Subject: [PATCH] drivers/base: return bus_add_driver() errors
Date: Tue, 20 Oct 2026 11:09:34 +0800 [thread overview]
Message-ID: <tencent_454B62AD90C40381288FCAD5C893EC310507@qq.com> (raw)
bus_add_driver() creates the driver's uevent attribute, adds the bus
driver groups and the bind/unbind files. When any of these fail it
only prints a message and still returns 0, leaving the driver on the
bus while the sysfs files user space needs to manage it are silently
missing: bind/unbind cannot be used and the uevent attribute cannot be
triggered. Nothing retries and the caller is told the registration
succeeded.
The device side of the same driver model already gets this right.
device_add() returns failures of the equivalent sysfs operations to
its caller and device_del() undoes each one, and driver_register()
already calls bus_remove_driver() when the group registration after
bus_add_driver() fails. Commit 85d2b0aa1703 ("module: don't ignore
sysfs_create_link() failures") made the same change to
module_add_driver() a few lines above, so the driver side is now the
only place in this function where a sysfs failure is discarded.
Propagate the errors so the existing unwind runs. The new
out_remove_module label calls module_remove_driver() before falling
through to out_detach: bus_remove_driver() pairs every operation
bus_add_driver() performs in reverse order, but the symlinks
module_add_driver() creates live in the module's sysfs directory, not
under drv->p->kobj, so the kobject teardown does not remove them.
The attribute and the groups need no explicit removal because they live
under drv->p->kobj, and kobject_cleanup() drops the sysfs directory for
the caller.
These failures are not expected on a working system: driver_ktype
always supplies sysfs_ops, so -EINVAL is unreachable, -EEXIST needs a
bus group to collide with built-in attributes, and -ENOMEM needs
memory pressure. The point is not a user-visible bug but keeping the
failure diagnosable and the resulting state consistent with the device
side.
Signed-off-by: level0000x <level_zero@qq.com>
---
drivers/base/bus.c | 27 +++++++++++----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index d17bd91..e5c8a12 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -772,28 +772,23 @@ int bus_add_driver(struct device_driver *drv)
}
error = driver_create_file(drv, &driver_attr_uevent);
- if (error) {
- printk(KERN_ERR "%s: uevent attr (%s) failed\n",
- __func__, drv->name);
- }
+ if (error)
+ goto out_remove_module;
+
error = driver_add_groups(drv, sp->bus->drv_groups);
- if (error) {
- /* How the hell do we get out of this pickle? Give up */
- printk(KERN_ERR "%s: driver_add_groups(%s) failed\n",
- __func__, drv->name);
- }
+ if (error)
+ goto out_remove_module;
if (!drv->suppress_bind_attrs) {
error = add_bind_files(drv);
- if (error) {
- /* Ditto */
- printk(KERN_ERR "%s: add_bind_files(%s) failed\n",
- __func__, drv->name);
- }
+ if (error)
+ goto out_remove_module;
}
return 0;
+out_remove_module:
+ module_remove_driver(drv);
out_detach:
driver_detach(drv);
out_del_list:
--
2.34.1
next reply other threads:[~2026-10-20 3:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 3:09 level0000x [this message]
2026-10-20 6:13 ` Greg Kroah-Hartman
2026-10-20 6:30 ` [PATCH v2] " level0000x
2026-10-20 6:35 ` [PATCH v4] " Yemingxuan
2026-10-20 6:49 ` Greg Kroah-Hartman
2026-10-20 7:02 ` [PATCH v5] " Yemingxuan
2026-10-20 6:58 ` Yemingxuan
2026-10-20 6:58 ` Yemingxuan
2026-10-20 6:59 ` [PATCH] " Yemingxuan
2026-10-20 7:00 ` [PATCH v5] " Yemingxuan
2026-10-20 7:01 ` Yemingxuan
2026-10-20 7:10 ` [PATCH v6] " Yemingxuan
2026-10-20 6:57 ` [PATCH v5] " Yemingxuan
2026-10-20 6:57 ` Yemingxuan
2026-10-20 6:58 ` Yemingxuan
2026-10-20 6:58 ` Yemingxuan
2026-10-20 6:58 ` Yemingxuan
2026-10-20 6:59 ` [PATCH] " Yemingxuan
2026-10-20 6:59 ` Yemingxuan
2026-10-20 7:00 ` Yemingxuan
2026-10-20 7:00 ` [PATCH v6] " Yemingxuan
2026-10-20 7:01 ` [PATCH v5] " Yemingxuan
2026-10-20 7:02 ` [PATCH v6] " Yemingxuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tencent_454B62AD90C40381288FCAD5C893EC310507@qq.com \
--to=level_zero@qq.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®