[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1411252027040.23174@pobox.suse.cz>
Date: Tue, 25 Nov 2014 20:29:31 +0100 (CET)
From: Jiri Kosina <jkosina@...e.cz>
To: Steven Rostedt <rostedt@...dmis.org>
cc: Petr Mladek <pmladek@...e.cz>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Seth Jennings <sjenning@...hat.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Vojtech Pavlik <vojtech@...e.cz>,
Miroslav Benes <mbenes@...e.cz>,
Christoph Hellwig <hch@...radead.org>,
Greg KH <gregkh@...uxfoundation.org>,
Andy Lutomirski <luto@...capital.net>,
live-patching@...r.kernel.org, x86@...nel.org, kpatch@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCHv3 2/3] kernel: add support for live patching
On Tue, 25 Nov 2014, Steven Rostedt wrote:
> It is not guaranteed from ftrace's stand point. What happens if we have
> a kprobe handler that modifies it for someplace else? Changing the ip
> address may not be a kpatch/kGraft privilege only.
This brings me back to the RFC patch I sent back then in october ... what
we really want to do is to at least warn about situations when we are
going to redirect code flow (through IPMODIFY) for function that has a
kprobe installed anywhere inside it. Otherwise the probe will silently
vanish (there is no way how to migrate it to the new function
automatically), which might be very confusing for uses (cosider systemtap,
for example).
I'll resurect my patch if noone beats me doing it. It should go in
together with the live patching framework I believe.
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/
Powered by blists - more mailing lists