Date: Tue, 5 May 2015 00:48:22 +0200 (CEST)
From: Jiri Kosina <jkosina@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
cc: Jiri Slaby <jslaby@suse.cz>, 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
In-Reply-To: <20150504154429.GA21537@treble.redhat.com>
Message-ID: <alpine.LNX.2.00.1505050036440.17961@pobox.suse.cz>
References: <1430739625-4658-1-git-send-email-jslaby@suse.cz> <1430742009-5895-1-git-send-email-jslaby@suse.cz> <20150504154429.GA21537@treble.redhat.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1661
Lines: 43

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.


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); plus it can cause the patching to 
  fail under certain circumstances

- 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)

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.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
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/