On Sun, Nov 8, 2026 at 10:56 PM Juergen Gross <[email protected]> wrote: > > On 08.11.26 23:39, Ian Rogers wrote: > > hypervisor_init() in drivers/base/hypervisor.c creates hypervisor_kobj > > with kobject_create_and_add() (which allocates a dynamic kobject using > > dynamic_kobj_ktype), and hypervisor_subsys_init() in > > drivers/xen/sys-hypervisor.c then overwrites hypervisor_kobj->ktype with > > &hyp_sysfs_kobj_type, which had no .release callback. > > > > Add hyp_sysfs_release() calling kfree(kobj) to preserve the dynamic > > kobject release behavior. > > > > Fixes: cff7e81b3dd7 ("xen: add /sys/hypervisor support") > > Signed-off-by: Ian Rogers <[email protected]> > > --- > > drivers/xen/sys-hypervisor.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c > > index 91923242a5ae..0e8a2cd69fd6 100644 > > --- a/drivers/xen/sys-hypervisor.c > > +++ b/drivers/xen/sys-hypervisor.c > > @@ -659,7 +659,13 @@ static const struct sysfs_ops hyp_sysfs_ops = { > > .store = hyp_sysfs_store, > > }; > > > > +static void hyp_sysfs_release(struct kobject *kobj) > > +{ > > + kfree(kobj); > > +} > > + > > static const struct kobj_type hyp_sysfs_kobj_type = { > > + .release = hyp_sysfs_release, > > .sysfs_ops = &hyp_sysfs_ops, > > }; > > > > Wouldn't it make sense to have a common function for just kfree(kobj)? > > In your series there are 3 instances of .release just doing kfree(kobj). > > In case this is not wanted or with using the suggested common .release > helper you can add my > > Reviewed-by: Juergen Gross <[email protected]>
Thanks Juergen! lib/kobject.c already has a static dynamic_kobj_release() that does this (and there are ~15 other places in the tree open-coding a static kfree(kobj) release wrapper), so include/linux/kobject.h + lib/kobject.c would be the natural home if we exported one. I kept them as local static functions here for two reasons: 1. Patches 2/9, 3/9, and 6/9 carry Fixes: tags, and keeping the small local callbacks avoids a dependency on a new driver-core export for backports. 2. Since kobjects are normally embedded in a larger struct and freed via container_of(), I wasn't sure whether Greg and Danilo would view an exported kfree(kobj) release helper (especially alongside __must_init) as an invitation for misuse on embedded kobjects. Unless Greg or Danilo would like dynamic_kobj_release() (or similar) exported now, I'll plan to keep the local callbacks for this series and can send a follow-up cleanup for the tree-wide callers if driver-core maintainers think a shared helper makes sense. Thanks, Ian > > > Juergen
