On Wed, 14 Mar 2018, Josh Poimboeuf wrote: > 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? Agreed. _ctor/_dtor both sound better. Miroslav -- 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
