In some cases, devtmpfs_create_node() can return error value.
So, make use of it.
Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
---
drivers/base/core.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 7dab705f2937..aaa3088e5456 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3405,7 +3405,9 @@ int device_add(struct device *dev)
if (error)
goto SysEntryError;
- devtmpfs_create_node(dev);
+ error = devtmpfs_create_node(dev);
+ if (error)
+ goto DevtmpfsError;
}
/* Notify clients of device addition. This call must come
@@ -3461,6 +3463,8 @@ int device_add(struct device *dev)
done:
put_device(dev);
return error;
+ DevtmpfsError:
+ device_remove_sys_dev_entry(dev);
SysEntryError:
if (MAJOR(dev->devt))
device_remove_file(dev, &dev_attr_dev);
--
2.25.1
Hi Longlong,
On Fri, Feb 10, 2023 at 09:54:42AM +0000, Longlong Xia wrote:
> In some cases, devtmpfs_create_node() can return error value.
> So, make use of it.
>
> Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
> ---
> drivers/base/core.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 7dab705f2937..aaa3088e5456 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3405,7 +3405,9 @@ int device_add(struct device *dev)
> if (error)
> goto SysEntryError;
>
> - devtmpfs_create_node(dev);
> + error = devtmpfs_create_node(dev);
> + if (error)
> + goto DevtmpfsError;
> }
>
> /* Notify clients of device addition. This call must come
> @@ -3461,6 +3463,8 @@ int device_add(struct device *dev)
> done:
> put_device(dev);
> return error;
> + DevtmpfsError:
> + device_remove_sys_dev_entry(dev);
> SysEntryError:
> if (MAJOR(dev->devt))
> device_remove_file(dev, &dev_attr_dev);
> --
> 2.25.1
>
After this change in -next as commit 31b4b6730fd4 ("driver core: add
error handling for devtmpfs_create_node()"), my test machines failed to
boot after the rootfs could not be mounted. I added some logging to see
which device was failing, which triggers a few times with the exact same
message:
device: 'btrfs-control': devtmpfs_create_node() failed, err = -17
with -17 being -EEXIST. I am not sure why this device is getting
registered more than once, it appears to occur during module insertion
though, as I am able to get to systemd starting within the initrd.
Should this particular return value be downgraded to a warning so that
the device still loads or should the driver be fixed? I have cc'd the
btrfs mailing list, in case they have any input.
Cheers,
Nathan
On Mon, Feb 13, 2023 at 05:14:27PM -0700, Nathan Chancellor wrote:
> Hi Longlong,
>
> On Fri, Feb 10, 2023 at 09:54:42AM +0000, Longlong Xia wrote:
> > In some cases, devtmpfs_create_node() can return error value.
> > So, make use of it.
> >
> > Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
> > ---
> > drivers/base/core.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index 7dab705f2937..aaa3088e5456 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -3405,7 +3405,9 @@ int device_add(struct device *dev)
> > if (error)
> > goto SysEntryError;
> >
> > - devtmpfs_create_node(dev);
> > + error = devtmpfs_create_node(dev);
> > + if (error)
> > + goto DevtmpfsError;
> > }
> >
> > /* Notify clients of device addition. This call must come
> > @@ -3461,6 +3463,8 @@ int device_add(struct device *dev)
> > done:
> > put_device(dev);
> > return error;
> > + DevtmpfsError:
> > + device_remove_sys_dev_entry(dev);
> > SysEntryError:
> > if (MAJOR(dev->devt))
> > device_remove_file(dev, &dev_attr_dev);
> > --
> > 2.25.1
> >
>
> After this change in -next as commit 31b4b6730fd4 ("driver core: add
> error handling for devtmpfs_create_node()"), my test machines failed to
> boot after the rootfs could not be mounted. I added some logging to see
> which device was failing, which triggers a few times with the exact same
> message:
>
> device: 'btrfs-control': devtmpfs_create_node() failed, err = -17
>
> with -17 being -EEXIST. I am not sure why this device is getting
> registered more than once, it appears to occur during module insertion
> though, as I am able to get to systemd starting within the initrd.
>
> Should this particular return value be downgraded to a warning so that
> the device still loads or should the driver be fixed? I have cc'd the
> btrfs mailing list, in case they have any input.
Apologies, I see now that the second patch in this series is logging for
this, sorry for not using or noticing that sooner.
I am now looking at some of my other test machines and I see messages
similar to the one above for other devices:
[ 16.268685] sound timer: failed to create snd/timer, ret = -17
[ 16.274666] ALSA: unable to register timer device (-17)
[ 16.500253] sound timer: failed to create snd/timer, ret = -17
[ 16.506124] ALSA: unable to register timer device (-17)
[ 18.273067] misc rfkill: failed to create rfkill, ret = -17
[ 18.464836] misc rfkill: failed to create rfkill, ret = -17
[ 19.366149] misc tun: failed to create net/tun, ret = -17
[ 19.371613] tun: Can't register misc device 200
[ 19.552362] misc tun: failed to create net/tun, ret = -17
[ 19.557839] tun: Can't register misc device 200
[ 23.124993] misc tun: failed to create net/tun, ret = -17
[ 23.130460] tun: Can't register misc device 200
[ 23.299267] misc tun: failed to create net/tun, ret = -17
[ 23.299319] tun: Can't register misc device 200
[ 27.050363] misc tun: failed to create net/tun, ret = -17
[ 27.055824] tun: Can't register misc device 200
[ 27.181496] misc tun: failed to create net/tun, ret = -17
So it seems like this is not a btrfs specific problem?
Cheers,
Nathan
On Mon, Feb 13, 2023 at 05:33:06PM -0700, Nathan Chancellor wrote:
> On Mon, Feb 13, 2023 at 05:14:27PM -0700, Nathan Chancellor wrote:
> > Hi Longlong,
> >
> > On Fri, Feb 10, 2023 at 09:54:42AM +0000, Longlong Xia wrote:
> > > In some cases, devtmpfs_create_node() can return error value.
> > > So, make use of it.
> > >
> > > Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
> > > ---
> > > drivers/base/core.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index 7dab705f2937..aaa3088e5456 100644
> > > --- a/drivers/base/core.c
> > > +++ b/drivers/base/core.c
> > > @@ -3405,7 +3405,9 @@ int device_add(struct device *dev)
> > > if (error)
> > > goto SysEntryError;
> > >
> > > - devtmpfs_create_node(dev);
> > > + error = devtmpfs_create_node(dev);
> > > + if (error)
> > > + goto DevtmpfsError;
> > > }
> > >
> > > /* Notify clients of device addition. This call must come
> > > @@ -3461,6 +3463,8 @@ int device_add(struct device *dev)
> > > done:
> > > put_device(dev);
> > > return error;
> > > + DevtmpfsError:
> > > + device_remove_sys_dev_entry(dev);
> > > SysEntryError:
> > > if (MAJOR(dev->devt))
> > > device_remove_file(dev, &dev_attr_dev);
> > > --
> > > 2.25.1
> > >
> >
> > After this change in -next as commit 31b4b6730fd4 ("driver core: add
> > error handling for devtmpfs_create_node()"), my test machines failed to
> > boot after the rootfs could not be mounted. I added some logging to see
> > which device was failing, which triggers a few times with the exact same
> > message:
> >
> > device: 'btrfs-control': devtmpfs_create_node() failed, err = -17
> >
> > with -17 being -EEXIST. I am not sure why this device is getting
> > registered more than once, it appears to occur during module insertion
> > though, as I am able to get to systemd starting within the initrd.
> >
> > Should this particular return value be downgraded to a warning so that
> > the device still loads or should the driver be fixed? I have cc'd the
> > btrfs mailing list, in case they have any input.
>
> Apologies, I see now that the second patch in this series is logging for
> this, sorry for not using or noticing that sooner.
>
> I am now looking at some of my other test machines and I see messages
> similar to the one above for other devices:
>
> [ 16.268685] sound timer: failed to create snd/timer, ret = -17
> [ 16.274666] ALSA: unable to register timer device (-17)
> [ 16.500253] sound timer: failed to create snd/timer, ret = -17
> [ 16.506124] ALSA: unable to register timer device (-17)
>
> [ 18.273067] misc rfkill: failed to create rfkill, ret = -17
> [ 18.464836] misc rfkill: failed to create rfkill, ret = -17
> [ 19.366149] misc tun: failed to create net/tun, ret = -17
> [ 19.371613] tun: Can't register misc device 200
> [ 19.552362] misc tun: failed to create net/tun, ret = -17
> [ 19.557839] tun: Can't register misc device 200
> [ 23.124993] misc tun: failed to create net/tun, ret = -17
> [ 23.130460] tun: Can't register misc device 200
> [ 23.299267] misc tun: failed to create net/tun, ret = -17
> [ 23.299319] tun: Can't register misc device 200
> [ 27.050363] misc tun: failed to create net/tun, ret = -17
> [ 27.055824] tun: Can't register misc device 200
> [ 27.181496] misc tun: failed to create net/tun, ret = -17
>
> So it seems like this is not a btrfs specific problem?
Ok, let me go revert the series for now. Longlong, please feel free to
resubmit after testing this a bit better.
thanks,
greg k-h
© 2016 - 2026 Red Hat, Inc.