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 - 2025 Red Hat, Inc.