mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yemingxuan <level_zero@qq.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] drivers/base: return bus_add_driver() errors
Date: Tue, 20 Oct 2026 14:59:28 +0800	[thread overview]
Message-ID: <tencent_EB02491E77AB9E275663CD961B5A2B89C508@qq.com> (raw)
In-Reply-To: <tencent_454B62AD90C40381288FCAD5C893EC310507@qq.com>

bus_add_driver() creates the driver's uevent attribute, adds the bus
driver groups and the bind/unbind files after the driver has already
been inserted into the bus and its module links have been made.  When
any of these fail it logs the failure and still returns 0.

The driver is then registered but incomplete: a driver without
bind/unbind cannot be bound or unbound from userspace, and a driver
without its uevent attribute can no longer emit uevent notifications.
driver_register() reports success, so neither the driver's init routine
nor its caller retries, and nothing else ever creates the missing
files.

The device side of the same driver model already treats the equivalent
steps this way: device_add() returns failures of the equivalent sysfs
operations to its caller, and device_del() undoes each one.
driver_register() already calls bus_remove_driver() when the group
registration after bus_add_driver() fails, and that branch is only
unreachable for failures inside bus_add_driver() because of the
unconditional successful return.

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.

The error messages are kept.  The return value of an initcall is not
printed by the initcall machinery, so dropping them would turn a
reported failure into a silent one.

These failures are not expected on a working system: driver_ktype
always supplies sysfs_ops, so -EINVAL is unreachable, no in-tree bus
defines a drv_group that collides with the built-in uevent, bind or
unbind attributes, and -ENOMEM needs memory pressure.  The point is not
a user-visible bug but keeping the driver model consistent with the
device side and leaving the failure reported.

Signed-off-by: Yemingxuan <level_zero@qq.com>
---
v2: 只改了格式,没有内容变化。补丁体与邮件信封的 From 头现在一致。

v3: 同 v2,修正了补丁 diff 格式(由 git format-patch 生成,含 diff --git
和 index 行),此前用的是 diff -u 的手工拼接版本。

v4: 保留了原来的 printk() 调用。前的版本删掉了它们,理由是"错误会传播",
但 initcall 的返回值不会被内核打印,删掉那些消息会让失败变得完全静默。

v5: 本版本没有任何代码变化,只是补上这节 changelog。
---

 drivers/base/bus.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index d17bd91..a63e55c 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -775,25 +775,28 @@ int bus_add_driver(struct device_driver *drv)
 	if (error) {
 		printk(KERN_ERR "%s: uevent attr (%s) failed\n",
 			__func__, drv->name);
+		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);
+		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);
+			goto out_remove_module;
 		}
 	}
 
 	return 0;
 
+out_remove_module:
+	module_remove_driver(drv);
 out_detach:
 	driver_detach(drv);
 out_del_list:
-- 
2.34.1


  parent reply	other threads:[~2026-10-20  6:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20  3:09 level0000x
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 [this message]
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_EB02491E77AB9E275663CD961B5A2B89C508@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®