Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755447AbbEEDoF (ORCPT ); Mon, 4 May 2015 23:44:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39332 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752431AbbEEDny (ORCPT ); Mon, 4 May 2015 23:43:54 -0400 Date: Mon, 4 May 2015 22:43:52 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: Jiri Slaby , live-patching@vger.kernel.org, sjenning@redhat.com, vojtech@suse.cz, mingo@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [RFC kgr on klp 0/9] kGraft on the top of KLP Message-ID: <20150505034352.GA20128@treble.redhat.com> References: <1430739625-4658-1-git-send-email-jslaby@suse.cz> <1430742009-5895-1-git-send-email-jslaby@suse.cz> <20150504154429.GA21537@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2601 Lines: 60 On Tue, May 05, 2015 at 12:48:22AM +0200, Jiri Kosina wrote: > On Mon, 4 May 2015, Josh Poimboeuf wrote: > > Why do we need multiple consistency models? > > Well, I am pretty sure we need always at least two: > > - the "immediate" one, where the code redirection flip is switched > unconditionally and immediately (i.e. exactly what we currently have in > Linus' tree); semantically applicable to many patches, but not all of > them > > - something that fills the "but not all of them" gap above. What's the benefit of having the "immediate" model in addition to the more comprehensive model? > Both of the solutions that have been presnted so far have some drawbacks > that need to be discussed further. To me, the "highlights" (in the > "drawbacks" space) are: > > - any method that is stack-checking-based basically means that we have to > functionally 100% rely on stack unwinding correctness. We have never > done that before, and current stack unwinder is not ready for that > (Josh is working on improving that); I wouldn't call it a drawback. More like a deal breaker :-) But yeah, I'm working on that. > plus it can cause the patching to fail under certain circumstances Assuming you're talking about the kGraft/kpatch hybrid RFC, it actually doesn't fail. It falls back to asynchronous lazy migration for any straggler tasks. > - the kGraft method is not (yet) able to patch kernel threads, and allows > for multiple instances of the patched functions to be running in > parallel (i.e. patch author needs to be aware of this constaint, and > write the code accordingly) Not being able to patch kthreads sounds like a huge drawback, if not a deal breaker. How does the patching state ever reach completion? > This is exactly why we are submitting the kGraft-on-klp patchset, so that > we have concurrent implementations (sharing the same goal) to compare, and > ultimately merge whatever the best possible outcome will be. Another big downside to kGraft, assuming you want the patching to complete within a realistic period of time, is that you have to wake up all the sleeping tasks and send them through their signal handling paths. I would say it's orders of magnitude more disruptive and much riskier compared to walking the stacks (again, assuming we can make stack walking "safe"). -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/