On Tue, Mar 13, 2018 at 04:54:48PM +0100, Petr Mladek wrote: > We might need to do some actions before the shadow variable is freed. > For example, we might need to remove it from a list or free some data > that it points to. > > This is already possible now. The user can get the shadow variable > by klp_shadow_get(), do the necessary actions, and then call > klp_shadow_free(). > > This patch allow to do this a more elegant way. The user could implement > the needed actions in a callback that is passed to klp_shadow_free() > as a parameter. The callback usually does reverse operations to > the init_func that can be called by klp_shadow_*alloc(). > > It is especially useful for klp_shadow_free_all(). There we need to do > these extra actions for each found shadow variable with the given ID. > > Note that the memory used by the shadow variable itself is still released > later by rcu callback. It is needed to protect internal structures that > keep all shadow variables. But free_func is called immediately. The shadow > variable must not be access anyway after klp_shadow_free() is called. > The user is responsible to protect this any suitable way. > > Be aware that free_func callback is called under klp_shadow_lock. It is > the same as for init_func in klp_shadow_alloc(). > > Signed-off-by: Petr Mladek <pmladek@xxxxxxxx> Makes sense, though I'm not sure "free" is the right name: a) "free" isn't the opposite of "init"; and b) it may be used for things other than freeing. Shall we call them constructor/destructor? -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
