On Thu, Jul 30, 2020 at 07:37:16AM +0200, Greg KH wrote: > On Thu, Jul 30, 2020 at 11:28:38AM +1000, Michael Ellerman wrote: > > [ Added Peter & Greg to Cc ] > > > > Thadeu Lima de Souza Cascardo <casca...@canonical.com> writes: > > > Commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ("kobject: return error > > > code if writing /sys/.../uevent fails") started returning failure when > > > writing to /sys/devices/vio/uevent. > > > > > > This causes an early udevadm trigger to fail. On some installer versions > > > of > > > Ubuntu, this will cause init to exit, thus panicing the system very early > > > during boot. > > > > > > Removing the bus_type from the parent device will remove some of the extra > > > empty files from /sys/devices/vio/, but will keep the rest of the layout > > > for vio devices, keeping them under /sys/devices/vio/. > > > > What exactly does it change? > > > > I'm finding it hard to evaluate if this change is going to cause a > > regression somehow. > > > > I'm also not clear on why removing the bus type is correct, apart from > > whether it fixes the bug you're seeing. > > > > > It has been tested that uevents for vio devices don't change after this > > > fix, they still contain MODALIAS. > > > > > > Signed-off-by: Thadeu Lima de Souza Cascardo <casca...@canonical.com> > > > Fixes: df44b479654f ("kobject: return error code if writing > > > /sys/.../uevent fails") > > > > AFAICS there haven't been any other fixes for that commit. Do we know > > why it is only vio that was affected? (possibly because it's a fake bus > > to begin with?) > > So there was an error previously, the core was ignoring it, and now it > isn't and to fix that you want to remove describing what bus a device is > on? > > Huh??? > > > > > cheers > > > > > diff --git a/arch/powerpc/platforms/pseries/vio.c > > > b/arch/powerpc/platforms/pseries/vio.c > > > index 37f1f25ba804..a94dab3972a0 100644 > > > --- a/arch/powerpc/platforms/pseries/vio.c > > > +++ b/arch/powerpc/platforms/pseries/vio.c > > > @@ -36,7 +36,6 @@ static struct vio_dev vio_bus_device = { /* fake > > > "parent" device */ > > > .name = "vio", > > > .type = "", > > > .dev.init_name = "vio", > > > - .dev.bus = &vio_bus_type, > > > }; > > Wait, a static 'struct device'? You all are playing with fire there. > That's a reference counted object, and should never be declared like > that at all. > > I see you register it, but never unregister it, why? Why is it even > needed? > > And if you remove the bus type of it, it will show up in a different > part of sysfs, so I think this patch will show a user-visable change, > right? > > thanks, > > greg k-h
As the comment says, it's a "fake parent device". There is a user-visible change, which is removing some attributes from the object, but it's still showing up on the same path. Returning an error code like df44b479654f does is also a user visible change and it breaks installer images that panic early on boot. I could investigate an alternative here, which would be not fail when writing to uevent for this specific fake device. Cascardo.