Helge Hafting wrote:
> decrement_usecount will return to the module _if_ the count
> didn't reach 0. If it does, it goes straight to whatever
> usually happens after the module returns.
This looks appealing, but you still need an unconditional
"decrement_module_count_and_return", like I proposed earlier,
because multiple decrement_usecount could race with removal,
so you'd still hit removed code.
Example:
...
decrement_usecount();
return; /* unsafe */
}
Now we have two CPUs executing this, and the third one will
remove the module.
Use count CPU 1 CPU 2 CPU 3
2 decrement ... ...
1 return 1x decrement ...
0 - return 2x remove
0 *CRASH* ... ...
The only case where decrement_usecount would work is if all
possible callers of decrement_usecount are serialized. I
can't think of any case where this is true, and just moving
the decrementing before the return(s) would improve anything
but perhaps the code structure, so I'm not sure if this would
be worth the potential and easily overlooked problems.
- 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 : Sun Jul 07 2002 - 22:00:09 EST