Re: [RFC] Migrating net/sched to new module interface

From: Roman Zippel (
Date: Sat Feb 15 2003 - 18:20:24 EST


On Fri, 14 Feb 2003, Werner Almesberger wrote:

> > Yes, and now compare how the solutions differ when the data is static and
> > when it's allocated.
> Do they ? Even if the data is static, it can become invalid
> (in the sense that accessing it from a callback would lead
> to some kind of undesirable behaviour, even though the access
> itself would work), so I don't quite see why the difference
> would matter.

Let's stay at the main problem, we have find out when it's safe to delete
an object. For dynamic objects you have the following options:
- callbacks: when the refcount becomes zero, we call a function to remove
  the object.
- failure: we just return -EBUSY and try again later.
- wait: we simply wait until the refcount becomes zero

Static objects and functions are freed by the module code and usually we
want to unregister them at module unload time, so there are basically two
- we use the module count via try_module_get/module_put
- we use your own refcount and must wait in module_exit until all users
  are gone

If we exclude the possibly-wait-forever-option, do you see the problem
for dynamic objects which also contain references to static data/
functions? Procfs entries are such objects, there is a count field for the
dynamic part and an owner field for the static part and proc_get_inode
always has to get two references. The interesting question is now, can we
get rid of one of them?
If the answer is no, it would mean we need two procfs APIs, one which can
be used from module_exit and another which can be used to remove dynamic
entries. OTOH if we want to avoid this it would mean we have to make one
or more of the above options generically usable.

I stop here, because before we can discuss possible solutions, we have to
agree, that this problem is real.
Rusty, did I make any mistake so far? I'd really like to have your opinion
too. You are free to flame me, if I made any mistake, but please do it
with a bit more substance than just accusing me of ignorance.

bye, Roman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:01:05 EST