linux-kernel - Re: [PATCHv4 0/3] Kernel Live Patching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Nov 2014 23:22:09 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Seth Jennings <sjenning@...hat.com>
cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Vojtech Pavlik <vojtech@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	Petr Mladek <pmladek@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
	Christoph Hellwig <hch@...radead.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	live-patching@...r.kernel.org, x86@...nel.org, kpatch@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 0/3] Kernel Live Patching

On Tue, 25 Nov 2014, Seth Jennings wrote:

> > I'd like to do quite some more testing and still finish some pending 
> > portions of code reviews on our side (especially to make sure that this 
> > can be easily extended to support any consistency model in the future).
> 
> Without knowing how that consistency code will look, how can we "make
> sure" that this code can be easily extended to support it?  

Alright, I probably wasn't precise enough ... I want to make sure that 
whatever path (paths) we chose for future consistency models, we will not 
have to redesign everything from scratch :)

But this is really rather about finishing some of the reviews that are 
still underway on our side.

> > Once we start collecting Reviewed-by's / Acked-by's on this patchset, I 
> > can establish a tree on git.kernel.org that we can use to collect any 
> > followup patches during 3.20 development cycle and send a pull request to 
> > Linus during 3.20 merge window .. if everybody agrees with this course of 
> > action, obviously.
> 
> I was hoping this first step would go into next via Steve's tree and go
> upstream for 3.20 (hopefully) from there.  I would be against anything
> that tries to expand the feature set before this base functionality gets
> upstream.  

Fully agreed. No more "core" features than what your current patchset 
implements should be added before the first merge.

> However, if we want to have a tree to gather fixes before 3.20, which I 
> think is what you are suggesting, that works for me.  

Yup, that's what I am suggesting indeed. I think it makes sense to keep 
this separate from Steven's tree -- we are ftrace users, but we aren't 
touching anything from its internal implementation really.

> We would need to agree explicitly that, in this tree, patches would need 
> both a RH and SUSE ack to be accepted.

Oh, absolutely agreed. Without ack from (at least) everyone in 
MAINTAINERS, nothing will be applied.

I made this suggestion purely to make things easier for everybody 
(especially wrt. merge pull request), not to complicate things by either 
playing political games, nor by having to go through proxy tree (tracing), 
where the "topical link" is rather loose.

Thanks,

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