Messages in this thread | | | Date | Fri, 3 Dec 2021 16:07:39 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH V2 2/2] kobject: wait until kobject is cleaned up before freeing module |
| |
On Mon, Nov 29, 2021 at 11:45:09AM +0800, Ming Lei wrote: > kobject_put() may become asynchronously because of > CONFIG_DEBUG_KOBJECT_RELEASE, so once kobject_put() returns, the caller may > expect the kobject is released after the last refcnt is dropped, however > CONFIG_DEBUG_KOBJECT_RELEASE just schedules one delayed work function > for cleaning up the kobject.
The caller should NOT expect the kobject to be released. That's the whole point of dynamic reference counted objects, you never "know" when the last object is released. This option just makes it obvious so that you know when to fix up code that has this assumption.
> Inside the cleanup handler, kobj->ktype and kobj->ktype->release are > required.
Yes. Is that a problem?
> It is supposed that no activity is on kobject itself any more since > module_exit() is started, so it is reasonable for the kobject user or > driver to expect that kobject can be really released in the last run of > kobject_put() in module_exit() code path. Otherwise, it can be thought as > one driver's bug since the module is going away.
Why is module_exit() somehow special here? What is so odd about that?
> When the ->ktype and ->ktype->release are allocated as module static > variable, it can cause trouble because the delayed cleanup handler may > be run after the module is unloaded.
Why is ktype and release part of module code?
What module kobject is causing this problem?
> Fixes the issue by flushing scheduled kobject cleanup work before > freeing module.
Why are modules special here?
And if you enable this option, and then start unloading kernel modules, yes, things can go wrong, but that's not what this kernel option is for at all.
This feels like a hack for not a real problem.
thanks,
greg k-h
| |