Roland McGrath <[EMAIL PROTECTED]> writes: > [...] > What the utrace interface has always said about this is, "So don't do > that." [...] > What I overlooked is that not just your data structures, but your > callbacks too might be going away, i.e. unloading the kernel module.
I don't think the module-unloading case is so special. If there exist races involving utrace detach, then they will affect long-lasting modules too that may want to do some utracing then some other stuff, then perhaps return to utracing again. In this scenario, the data too is volatile or could be repurposed between utrace "sessions". Such a module would need to know positively when no further callbacks will arrive. > [...] For global engines' detach, one option is to offer no help > with your own data structures but to solve the module-unload problem > using the module refcount. [...] If having a per-cpu counter vector is sufficiently low weight for utrace to update it around every callback, how about letting a utrace engine specify an (optional?) percpu-integer vector? Then, the utrace client could use a similar synchronization algorithm as that of module/refcount unloading to assure itself of a complete and final utrace detach. It could even opt to reuse the counters between engines, or between utracing sessions, if it knows that its data/code lifetimes can work with that. - FChE
