> On Nov 20, 2018, at 4:42 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Tue, Nov 13, 2018 at 05:07:20AM -0800, Nadav Amit wrote: >> v4->v5: >> - Fix Xen breakage [Damian Tometzki] >> - BUG_ON() when poking_mm initialization fails [PeterZ] >> - Better comments on "x86/mm: temporary mm struct" >> - Cleaner removal of the custom poker > > I'll re-iterate my position: it is impossible for the text not to match, > and if it somehow does not match, something went sideways in an > unrecoverably fashion. > > text_poke() must not fail, ever. If it does, our text is inconsistent > and we must abort/panic/bug. > > The only way I will accept anything else is if someone can come up with > a sensible scenario of text_poke() failing and recovering from it. > AFAICT there is no possible way to gracefully recover. > > Consider a jump label with multiple patch sites; we patch the first, > then fail. In order to restore to a sane state, we must undo the > patching of the first, but undoing text_poke() fails again. Then > what? > > Allowing text_poke() to fail only creates an unfixable mess. Esp. since > there is no sane scenario under which is can fail. Ok, ok... I tried to stand my ground, but I guess I failed. I don’t feel that strongly about this assertion to argue with you. I’m just the “chicken” kind of guy. Yet, take into consideration that I will need to use you as my “vest” once I get being “shot” for adding BUG_ON(). ;-) I will send another version tonight, assuming no new issues are raised. Regards, NAdav
