On Thu 2017-10-19 17:44:32, Jason Baron wrote: > So for atomic replace, it seems as if we don't want to allow replaced > patches to be re-enabled but instead, allow them to rmmod/insmod'ed to > allow revert. > > In your above proposed model around immediate, if all patches are > immediate then the atomic replace doesn't allow any of the previous > patches to be removed from the kernel via rmmod, while if all patches > are handled using the consistency model then all patches previous to the > atomic replace patch could be removed via rmmod. So this would simplify > the logic around when replaced patches could removed. yes > I was thinking in the current model to only allow the one preceding > patch to the atomic replace patch to be rmmod'able, if the atomic > replace patch was using the consistency model (to avoid complications > with immediate functions/patches). And this could be extended to all > *all* patches previous to the atomic replace patch to be rmmod'able when > we move to the proposed model around immediates. So I don't think this > should hold up the atomic replace patches? Yes, this sounds reasonable from the atomic replace patch point of view. Well, the consistency model is broken at the moment when immediate flag is used. We should fix this ASAP. IMHO, the fix might need to go upstream before the atomic replace feature. It might be even stable material. Best Regards, Petr PS: One problem is that there are some conferences (Kernel Summit, Open Source Summit) next week. At least all livepatch-related SUSE people will be less reachable. -- 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
