Date: Tue, 5 May 2015 08:14:50 +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: <20150505034352.GA20128@treble.redhat.com>
Message-ID: <alpine.LNX.2.00.1505050756570.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> <alpine.LNX.2.00.1505050036440.17961@pobox.suse.cz> <20150505034352.GA20128@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: 2186
Lines: 55

On Mon, 4 May 2015, Josh Poimboeuf wrote:

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

Fair enoungh, I agree that in case of the hybrid aproach you're proposing 
the immediate model is not necessary.

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

It depends on bringing some sanity to freezing / parking / signal handling 
for kthreads, which is an independent work in progress in parallel.

> How does the patching state ever reach completion?

kthread context always calls the old code and it doesn't block the 
finalization; that's basically a documented feature for now.

That surely is a limitation and something the patch author has to be aware 
of, but I wouldn't really consider it a show stopper for now, for the 
reason pointed out above; it'll eventually be made to work, it's not a 
substantial issue.

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

Agreed ...  under the condition that it can be made really 100% reliable 
*and* we'd be reasonably sure that we will be able to realistically 
achieve the same goal on other architectures as well. Have you even 
started exploring that space, please?

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/