On Tue 2017-10-17 11:02:29, Miroslav Benes wrote: > On Tue, 10 Oct 2017, Jason Baron wrote: > > On 10/06/2017 06:32 PM, Josh Poimboeuf wrote: > > > I don't really like allowing a previously replaced patch to replace the > > > current patch. It's just more unnecessary complexity. I am sorry to say but it really makes the code too complex. > > > If the user > > > wants to atomically revert back to kpatch-a, they should be able to: > > > > > > rmmod kpatch-a > > > insmod kpatch-a.ko > > > > > Right - that's how I sent v1 (using rmmod/insmod to revert), but it > > didn't account for the fact the patch or some functions may be marked > > 'immediate' and thus its not possible to just do 'rmmod'. Thus, since in > > some cases 'rmmod' was not feasible, I thought it would be simpler from > > an operational pov to just say we always revert by re-enabling a > > previously replaced patch as opposed to rmmod/insmod. > > > Hm. Would it make sense to remove immediate and rely only on the > consistency model? At least for the architectures where the model is > implemented (x86_64)? > > If not, then I'd keep such modules there without a possibility to remove > them ever. If its functionality was required again, it would of course > mean to insmod a new module with it. I am fine with this compromise. It seems to be the only way to keep the livepatch code somehow sane. Best Regards, Petr -- 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
