Live-Patching Archive on lore.kernel.org
 help / color / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Jessica Yu <jeyu@kernel.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	mhiramat@kernel.org, bristot@redhat.com, jbaron@akamai.com,
	torvalds@linux-foundation.org, tglx@linutronix.de,
	mingo@kernel.org, namit@vmware.com, hpa@zytor.com,
	luto@kernel.org, ard.biesheuvel@linaro.org,
	live-patching@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()
Date: Wed, 22 Jan 2020 15:42:39 -0600
Message-ID: <20200122214239.ivnebi7hiabi5tbs@treble> (raw)
In-Reply-To: <alpine.LSU.2.21.2001221052331.15957@pobox.suse.cz>

On Wed, Jan 22, 2020 at 11:09:56AM +0100, Miroslav Benes wrote:
> 
> > > > At this point, I only see downsides of -flive-patching, at least until
> > > > we actually have real upstream code which needs it.
> > > 
> > > Can you explain this? The option makes GCC to avoid optimizations which 
> > > are difficult to detect and would make live patching unsafe. I consider it 
> > > useful as it is, so if you shared the other downsides and what you meant 
> > > by real upstream code, we could discuss it.
> > 
> > Only SLES needs it right?  Why inflict it on other livepatch users?  By
> > "real upstream code" I mean there's no (documented) way to create live
> > patches using the method which relies on this flag.  So I don't see any
> > upstream benefits for having it enabled.
> 
> I'd put it differently. SLES and upstream need it, RHEL does not need it. 
> Or anyone using kpatch-build.

I'm confused about why you think upstream needs it.

Is all the tooling available somewhere?  Is there documentation
available which describes how to build patches using that method from
start to finish?  Are there actual users other than SUSE?

BTW, kpatch-build has a *lot* of users other than RHEL.  All its tooling
and documentation are available on Github.

> It is perfectly fine to prepare live patches just from the source code
> using upstream live patching infrastructure. 

Do you mean the dangerous method used by the livepatch sample code which
completely ignores interprocedural optimizations?  I wouldn't call that
perfectly fine.

> After all, SLES is nothing else than upstream here. We were creating live 
> patches manually for quite a long time and only recently we have been 
> using Nicolai's klp-ccp automation (https://github.com/SUSE/klp-ccp).
> 
> So, everyone using upstream directly relies on the flag, which seems to be 
> a clear benefit to me. Reverting the patch would be a step back.

Who exactly is "everyone using upstream"?

From what I can tell, kpatch-build is the only known way (to those
outside of SUSE) to make safe patches for an upstream kernel.  And it
doesn't need this flag and the problems associated with it: performance,
LTO incompatibility, clang incompatibility (I think?), the GCC dead code
issue.

-- 
Josh


  reply index

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20191007081945.10951536.8@infradead.org>
     [not found] ` <20191008104335.6fcd78c9@gandalf.local.home>
     [not found]   ` <20191009224135.2dcf7767@oasis.local.home>
     [not found]     ` <20191010092054.GR2311@hirez.programming.kicks-ass.net>
     [not found]       ` <20191010091956.48fbcf42@gandalf.local.home>
     [not found]         ` <20191010140513.GT2311@hirez.programming.kicks-ass.net>
     [not found]           ` <20191010115449.22044b53@gandalf.local.home>
     [not found]             ` <20191010172819.GS2328@hirez.programming.kicks-ass.net>
     [not found]               ` <20191011125903.GN2359@hirez.programming.kicks-ass.net>
     [not found]                 ` <20191015130739.GA23565@linux-8ccs>
     [not found]                   ` <20191015135634.GK2328@hirez.programming.kicks-ass.net>
2019-10-15 14:13                     ` Miroslav Benes
2019-10-15 15:06                       ` Joe Lawrence
2019-10-15 15:31                         ` Jessica Yu
2019-10-15 22:17                           ` Joe Lawrence
2019-10-15 22:27                             ` Steven Rostedt
2019-10-16  7:42                               ` Peter Zijlstra
2019-10-16 10:15                                 ` Miroslav Benes
2019-10-21 15:05                                 ` Josh Poimboeuf
2020-01-20 16:50                                   ` Josh Poimboeuf
2020-01-21  8:35                                     ` Miroslav Benes
2020-01-21 16:10                                       ` Josh Poimboeuf
2020-01-22 10:09                                         ` Miroslav Benes
2020-01-22 21:42                                           ` Josh Poimboeuf [this message]
2020-01-28  9:28                                             ` Miroslav Benes
2020-01-28 15:00                                               ` Josh Poimboeuf
2020-01-28 15:40                                                 ` Petr Mladek
2020-01-28 17:02                                                   ` Josh Poimboeuf
2020-01-29  0:46                                                     ` Jiri Kosina
2020-01-29  2:17                                                       ` Josh Poimboeuf
2020-01-29  3:14                                                         ` Jiri Kosina
2020-01-29 12:28                                                     ` Miroslav Benes
2020-01-29 15:59                                                       ` Josh Poimboeuf
2020-01-30  9:53                                                         ` Petr Mladek
2020-01-30 14:17                                                           ` Josh Poimboeuf
2020-01-31  7:17                                                             ` Petr Mladek
2020-01-22 12:15                                         ` Miroslav Benes
2020-01-22 15:05                                           ` Miroslav Benes
2020-01-22 22:03                                             ` Josh Poimboeuf
2020-01-23 10:19                                               ` Martin Jambor
2019-10-16  7:49                               ` Peter Zijlstra
2019-10-16 10:20                                 ` Miroslav Benes
2019-10-16 13:29                                   ` Miroslav Benes
2019-10-18 13:03                                     ` Jessica Yu
2019-10-18 13:40                                       ` Petr Mladek
2019-10-21 14:14                                         ` Jessica Yu
2019-10-21 15:31                                         ` Josh Poimboeuf
2019-10-22  8:27                                       ` Miroslav Benes
2019-10-22 14:31                                         ` Josh Poimboeuf
2019-10-23  9:04                                           ` Miroslav Benes
2019-10-16  6:51                         ` Miroslav Benes
2019-10-16  9:23                           ` Peter Zijlstra
2019-10-16  9:36                             ` Jessica Yu
2019-10-16  9:51                               ` Peter Zijlstra
2019-10-16 12:39                           ` Peter Zijlstra
2019-10-22  8:45                             ` Miroslav Benes

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=20200122214239.ivnebi7hiabi5tbs@treble \
    --to=jpoimboe@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bristot@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jbaron@akamai.com \
    --cc=jeyu@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=namit@vmware.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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

Live-Patching Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/live-patching/0 live-patching/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 live-patching live-patching/ https://lore.kernel.org/live-patching \
		live-patching@vger.kernel.org
	public-inbox-index live-patching

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.live-patching


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git