Re: [PATCH] drivers/base: return bus_add_driver() errors

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Oct 20, 2026 at 11:09:34AM +0800, level0000x wrote:
> 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
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot