linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	Seth Jennings <sjenning@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Jiri Slaby <jslaby@suse.cz>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching
Date: Wed, 07 May 2014 07:49:25 +0900	[thread overview]
Message-ID: <536966F5.2020600@hitachi.com> (raw)
In-Reply-To: <20140506083346.2c96b8ad@gandalf.local.home>

(2014/05/06 21:33), Steven Rostedt wrote:
> On Tue, 6 May 2014 07:12:11 -0500
> Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
>> Live patching is a very sensitive and risky operation, and from a kernel
>> standpoint we should make it as safe as we reasonably can.  But we can't
>> do much about careless users.  Ultimately the risk is in the hands of
>> the user and their choice of patches.  They need to absolutely
>> understand all the implications of patching a particular function.  If
>> the patch changes the way a function interacts with some external data,
>> then they're starting to tempt fate and they need to be extra careful.
>> This care needs to be taken for *all* kernel functions, not just for the
>> few that are called from kernel threads.
> 
> Ideally the kpatch tools should be able to somewhat prevent users from
> doing damage. Or at least make them type a sentence that says:
> 
>   I know what I'm doing and will not blame anyone but myself if this
>   kills the system along with all my puppies and kittens.
> 
> I'm guessing that kpatch needs to be marketed that a distro or "hired
> help" will be creating the patch and the admin only needs to "trust"
> the one that gave them the kpatch module to load. All the
> testing/checking that the module works will be done by kernel
> developers and not by any "users".

I strongly agreed. Desktop/Cloud users may not care about it, most of
users just update kernel and reboot. Somewhat "enterprise" users may
also like to do "rolling update" their cluster systems. Only limited
mission critical non-stop systems require it. And since they usually
don't want to loose distro support, all binary patches will be provided
and tested by distro kernel developers, not by users itself. :)

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com



  reply	other threads:[~2014-05-06 22:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01 15:52 [RFC PATCH 0/2] kpatch: dynamic kernel patching Josh Poimboeuf
2014-05-01 15:52 ` [RFC PATCH 1/2] kpatch: add TAINT_KPATCH flag Josh Poimboeuf
2014-05-01 15:52 ` [RFC PATCH 2/2] kpatch: add kpatch core module Josh Poimboeuf
2014-05-01 20:45 ` [RFC PATCH 0/2] kpatch: dynamic kernel patching Andi Kleen
2014-05-01 21:01   ` Josh Poimboeuf
2014-05-01 21:06     ` Andi Kleen
2014-05-01 21:27       ` Josh Poimboeuf
2014-05-01 21:39         ` Josh Poimboeuf
2014-05-02  1:30       ` Masami Hiramatsu
2014-05-02  8:37 ` Jiri Kosina
2014-05-02 13:29   ` Josh Poimboeuf
2014-05-02 13:10 ` Jiri Kosina
2014-05-02 13:37   ` Josh Poimboeuf
2014-05-05 23:34   ` David Lang
2014-05-05 23:52     ` Jiri Kosina
2014-05-06  1:59       ` David Lang
2014-05-06 12:17         ` Josh Poimboeuf
2014-05-06  7:32       ` Ingo Molnar
2014-05-06  8:03         ` Jiri Kosina
2014-05-06 12:23         ` Josh Poimboeuf
2014-05-07 12:19           ` Ingo Molnar
2014-05-09  1:46             ` David Lang
2014-05-09  2:45               ` Steven Rostedt
2014-05-09  4:07               ` Masami Hiramatsu
2014-05-05  8:55 ` Ingo Molnar
2014-05-05 13:26   ` Josh Poimboeuf
2014-05-05 14:10     ` Frederic Weisbecker
2014-05-05 18:43       ` Ingo Molnar
2014-05-05 21:49         ` Frederic Weisbecker
2014-05-06 12:12           ` Josh Poimboeuf
2014-05-06 12:33             ` Steven Rostedt
2014-05-06 22:49               ` Masami Hiramatsu [this message]
2014-05-06 14:05             ` Frederic Weisbecker
2014-05-06 14:50               ` Josh Poimboeuf
2014-05-07 12:24                 ` Ingo Molnar
2014-05-07 15:41                   ` Josh Poimboeuf
2014-05-07 15:57                     ` Ingo Molnar
2014-05-07 16:43                       ` Josh Poimboeuf
2014-05-07 22:56                       ` David Lang
2014-05-08  6:12                         ` Ingo Molnar
2014-05-08  6:50                           ` David Lang
2014-05-08  7:08                             ` Ingo Molnar
2014-05-08  7:29                               ` Masami Hiramatsu
2014-05-08 12:48                               ` Josh Poimboeuf
2014-05-09  6:21                                 ` Masami Hiramatsu
2014-06-14 20:31                               ` Pavel Machek
2014-06-15  6:57                                 ` Ingo Molnar
2014-05-06 11:45         ` Masami Hiramatsu
2014-05-06 12:26           ` Steven Rostedt
2014-05-06 22:33             ` Masami Hiramatsu
2014-05-16 16:27             ` Jiri Kosina
2014-05-16 17:14               ` Josh Poimboeuf
2014-05-20  9:37                 ` Jiri Kosina
2014-05-20 12:59                   ` Josh Poimboeuf
2014-05-16 18:09               ` Masami Hiramatsu
2014-05-17 22:46                 ` Vojtech Pavlik
2014-05-16 18:55               ` Steven Rostedt
2014-05-16 22:32                 ` Jiri Kosina
2014-05-17  0:27                   ` Steven Rostedt
2014-05-17  7:10                     ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=536966F5.2020600@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=jpoimboe@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sjenning@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).