Jamie Lokier wrote:
> The more I think about it, the more I think the `owner' thing in
> file_operations et al. is the right thing in all cases,
What troubles me most in this discussion is that nobody seems to
think of how these issues affect non-modules.
Entry-after-removal is an anomaly in the subsystem making that call.
Fixing it for modules is fine as long as only modules will ever
un-register, but what do you do if non-module code ever wants to
un-register too ? (E.g. think hot-plugging or software devices.)
Invent some pseudo-module framework for it ? Require all code using
that subsystem to be a module ? What happens if there are multiple
registrations per chunk of code ?
Besides, a common pattern for those "hold this down, kick that, then
slowly count to ten, and now it's safe to release" solutions seems
to be that it takes roughly ten times as long to find the race
condition buried deep within them, than it took for the respective
predecessor.
I'm not sure the incremental band aid approach works in this case.
I'm sorry that I don't have to offer anything more constructive at
the moment, but I first want to build some testing framework. One
oops says more than ten pages of analysis explaining a race
condition :-)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ - 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 : Mon Jul 15 2002 - 22:00:14 EST