Re: [RFC 1/2] core: Add generic object registry implementation

[Greg Kroah-Hartman]

On Thu, Nov 06, 2014 at 05:13:24PM +0100, Thierry Reding wrote:
> On Thu, Nov 06, 2014 at 11:25:32AM +0100, Thierry Reding wrote:
> > On Wed, Nov 05, 2014 at 06:18:15PM -0800, Greg Kroah-Hartman wrote:
> [...]
> > > Sure, document it better if you want, but I think something needs to be
> > > done differently if at all possible.
> > 
> > try_module_get() is the only way I know of that ensures that the code of
> > a module stays around. Everytime we give out a new reference to a record
> > we also need to increment the module reference count accordingly to make
> > sure the underlying code doesn't go away all of a sudden.
> > 
> > I guess that's not entirely accurate. The module reference count doesn't
> > have to be increment for every record reference, it only needs to track
> > each record. So the try_module_get() and module_put() could move into
> > registry_add() and registry_get(), respectively. But the ->owner field
> > would still be in the record structure.
> 
> On further thought I don't think this will work either. Given that the
> record can be removed from the registry while somebody else still has a
> reference to it, the module owning the record must stay around as long
> as there's a reference to the record.
> 
> Maybe the module reference count needs to be incremented when the record
> is initialized and decremented when the record is released.

The module reference count will never work as it is racy (you can't have
the module itself do the incrementing, which is what is happening here).

I'd argue that the module reference isn't needed at all, because if the
module shuts down and wants to be removed, it will have properly cleaned
up all of its data structures already, right?  So why use it?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/