Re: [PATCH v2] params: serialize lookup_or_create_module_kobject()

[Jiakai Xu]

Hi Andrew,

Thanks for the review.

> You're sure we there's no race with module removal as well?

Yes.  The two kobject populations in module_kset have different
lifecycles, and neither can race with the serialized lookup-and-create
in a harmful way:

1. The kobjects this patch serializes belong to built-in modules.
   lookup_or_create_module_kobject() has three callers:
   kernel_add_sysfs_param() and the boot cmdline paths, which are all
   __init and run before concurrency exists, and module_add_driver()
   at runtime.  Once created, a built-in module kobject is never
   deleted: nothing in this path ever calls kobject_del(), and
   module_kobj_release() only completes ->kobj_completion (it does not
   even free the object).  So there is no removal side for these
   kobjects at all.

2. Loadable modules create a separate kobject per module
   (mod->mkobj, in mod_sysfs_init()).  A loadable module cannot
   collide with the lookup either: mod_sysfs_init() itself does
   kset_find_obj() first and refuses to load when a kobject with the
   same name already exists ("module is already loaded"), and
   add_unformed_module() checks for name collisions again under
   module_mutex via module_patient_check_exists().  So a loadable
   module never registers a same-named kobject while a driver
   registration holds our mutex, and free_module()/mod_sysfs_teardown()
   only ever kobject_put() their own mkobj.

3. Even if a concurrent kobject were being removed from module_kset,
   kset_find_obj() uses kobject_get_unless_zero(), so a dying kobject
   whose reference count has already dropped to zero is simply not
   found and we would create a fresh one.

The only remaining window I can see is within kobject core itself
(between kobject_get_unless_zero() and release), which is not this
code's responsibility to serialize.

> minor: this could be static inside lookup_or_create_module_kobject().

Sure, will do in v3.

Thanks,

--
Jiakai Xu