On 11/27, Andreas Dilger wrote: > On Nov 27, 2017, at 4:17 PM, Riccardo Schirone <sirmy15@xxxxxxxxx> wrote: > > > > Even when kobject_init_and_add/kset_register fail, the kobject has been > > already initialized and the refcount set to 1. Thus it is necessary to > > release the kobject/kset, to avoid the memory associated with it hanging > > around forever. > > This seems like a bad programming model. It doesn't make sense if the > "init" or "register" function returns an error that you would still have > to call "put" or "unregister" on the object. Why not just handle the > cleanup at the end of "kobject_init_and_add()" or "kobject_register()" > if there is an error instead of putting the burden on every caller? > > If open() returns an error, I don't need to call close(), and if malloc() > fails I don't need to call free(), etc. > > Cheers, Andreas > I agree it seems weird at first, but it looks to me the examples you made involve the *creation* of new objects, so it makes sense that the function, in case of errors, does not create them at all. In this case though the kobject_init_and_add is really just a shortcut for kobject_init + kobject_add and none of these functions create something for you. It's the caller's job to allocate the necessary memory, so I think that's the reason why it's still the caller that calls kobject_put when there's something wrong. Instead, in kobject_create_and_add, where the creation of the kobject is inside the function, the kobject is cleaned up if something wrong happens. Those are my thoughts anyway. Regards, Riccardo
