On Tue, Feb 18, 2003 at 02:22:57PM -0300, Werner Almesberger wrote:
> Next round: possible remedies and their side-effects. As
> usual, if you disagree with something, please holler.
>
> If yes, let's look at possible (and not overly insane) solutions,
> using remove_proc_entry as a case study:
Hi Werner,
Thanks for putting together this list; I've been following this thread for
a while and it seems that the discussion always deteriorates into
semantics. Anyway, I think there is an eighth possible solution to the
list you proposed.
Just to be specific, the requirements for the proc entry stuff are:
a) a mechanism needs to be defined to indicate that the entry is no longer
needed (something that starts the delete process -- ie, remove_proc_entry),
b) the code must conform to a system that ensures de->data will not be used
after the "release" code is executed, and
c) the "release" code must be eventually executed.
Assuming these requirements are really requirements (your options 1 and 4
don't seem to meet these) then an "eighth" solution is:
8) Have the unregister code (remove_proc_entry) set an external flag (eg,
de->data_is_there), and update all users of de->data to check the flag
before following the pointer.
Option 8 may not qualify as "sane", but I think it is important to add it
because it is what the module code is currently using. Thus, one need not
look at the module stuff as a "special case", but as a general (if
complicated) resource management solution.
Finally, one could probably apply any of the "options" for any dynamically
allocated memory. It is interesting that Linus seems to prefer option 2/7
(from the recent kobject work and CodingStyle).
If I've missed something, please let me know.
-Kevin
> 1) still don't kfree, and leave it to the user to somehow
> minimize the damage. (Good luck :-)
>
> 2) add a callback that is invoked when the proc entry gets
> deleted. (This callback may be called before remove_proc_entry
> completes.) Problem: unload/return race for modules.
>
> 3) change remove_proc_entry or add remove_proc_entry_wait that
> works like remove_proc_entry, but blocks until the entry is
> deleted. Problem: may sleep "forever".
>
> 4) make remove_proc_entry return an indication of whether the
> entry was successfully removed or not. Problem: if it
> wasn't, what can we do then ?
>
> 5) like above, but don't remove the entry if we can't do it
> immediately. Problem: there's no notification for when we
> should try again, so we'd have to poll.
>
> 6) export the lookup mechanism, and let the caller poll for
> removal. Problem: races with creation of a new entry with
> the same name.
>
> 7) transfer ownership of de->data to procfs, and set some
> (possibly configurable) destruction policy (e.g. always
> kfree, or such). Similar to 2), but less flexible.
-- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin@koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:40 EST