[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150121143620.GA2943@cerebellum.variantweb.net>
Date: Wed, 21 Jan 2015 08:36:20 -0600
From: Seth Jennings <sjenning@...hat.com>
To: Jiri Kosina <jkosina@...e.cz>
Cc: Li Bin <huawei.libin@...wei.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Vojtech Pavlik <vojtech@...e.cz>, Jiri Slaby <jslaby@...e.cz>,
Miroslav Benes <mbenes@...e.cz>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org, lizefan@...wei.com,
guohanjun@...wei.com, zhangdianfang@...wei.com, xiexiuqi@...wei.com
Subject: Re: [PATCH 1/2] livepatch: Revert "livepatch: enforce patch stacking
semantics"
On Wed, Jan 21, 2015 at 03:06:38PM +0100, Jiri Kosina wrote:
> On Wed, 21 Jan 2015, Li Bin wrote:
>
> > This reverts commit 83a90bb1345767f0cb96d242fd8b9db44b2b0e17.
> >
> > The method that only allowing the topmost patch on the stack to be
> > enabled or disabled is unreasonable. Such as the following case:
> >
> > - do live patch1
> > - disable patch1
> > - do live patch2 //error
> >
> > Now, we will never be able to do new live patch unless disabing the
> > patch1 although there is no dependencies.
>
> Unregistering disabled patch still works and removes it from the list no
> matter the position.
>
> So what exactly is the problem?
>From a quick glance, it seems that what this set does is it only
enforces the stacking requirements if two patches patch the same
function.
I'm not sure if that is correct logically or correctly implemented by
these patches yet.
Seth
>
> --
> Jiri Kosina
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists