Messages in this thread | | | Date | Wed, 30 Aug 2017 09:20:25 -0500 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v4 1/3] livepatch: add (un)patch callbacks |
| |
On Wed, Aug 30, 2017 at 09:27:16AM -0400, Joe Lawrence wrote: > > So instead of 'obj->pre_patch_callback_done', how about > > 'obj->callbacks_enabled'? > > > > It could be set in the following cases: > > > > a) if the object has a pre_patch callback, set obj->callbacks_enabled > > after the pre_patch callback succeeds; > > > > b) else, if the patch does *not* have a pre_patch callback, set > > obj->callbacks_enabled after klp_patch_object() succeeds. > > > > And the variable would need to be cleared after the post_unpatch > > callback was run. > > > > It's a bit complicated, but that seems to be the most logicial behavior > > as far as I can tell. > > > > Thoughts? > > What if we flip it around as "callbacks_disabled"? By default, kzalloc > would init as false. It would only be set to true if the pre-patch > callback is provided and if it returns failure. Would that reduce the > number of conditions when we need to set this var?
Yeah, 'callbacks_disabled' sounds better.
> Also, as you noted, I think it would need to reset/cleared after the > post-patch callback. (For the livepatch-already-loaded cases.)
Since it can only be set when the pre-patch fails, I think it would only need to be cleared after post-unpatch?
Or another alternative would be to unconditionally clear and/or set it in klp_pre_patch_callback() so that its previous value doesn't matter.
-- Josh
| |