Live-Patching Archive on lore.kernel.org
 help / color / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Miroslav Benes <mbenes@suse.cz>,
	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>,
	nstange@suse.de
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()
Date: Thu, 30 Jan 2020 10:53:46 +0100
Message-ID: <20200130095346.6buhb3reehijbamz@pathway.suse.cz> (raw)
In-Reply-To: <20200129155951.qvf3tjsv2qvswciw@treble>

On Wed 2020-01-29 09:59:51, Josh Poimboeuf wrote:
> In retrospect, the prerequisites for merging it should have been:

OK, let me do one more move in this game.


> 1) Document how source-based patches can be safely generated;

I agree that the information are really scattered over many files
in Documentation/livepatch/. Anyway, there is a lot of useful
hints:

   + structure and behavior of the livepatch module, link
     to a sample, limitations, are described in livepatch.rst

   + many other catches are described in the other files:
     callbacks, module-elf-fomat, cumulative-patches,
     system-state.

Yes, it would be great to have a better structure, more information.
But do not get me wrong. Anyone, Joe definitely, is able to create
livepatch from sources by this information.

Anyone could play with it, ask questions, and improve the
documentation. Better documentation would help but it is
not a blocker, definitely.


> 2) Fix the scheduler performance regression;

The optimizations are disabled only when livepatching is enabled.
I would consider this as a prize for the feature. There are
many things like this.

As it was said. It was 1-3 percent in scheduler microbenchmark.
It would make sense to fix it only when it causes such a regression
in real workloads. Do you have any?


> 3) Figure out if there are any other regressions by detecting which
>    function interfaces are affected by the flag and seeing if they're
>    hot path;

IMHO, benchmarks are much more effective and we spent non-trivial
resources when running them.


> 4) Provide a way for the N-1 users to opt-out

AFAIK, the only prize is the 1-3 percent scheduler performance degradation.
If you really do not want to pay this prize, let's make it configurable.

But the option is definitely needed when source livepatches are used.
There is no other reasonable way to detect and workaround these
problems. For this, it has to be in upstream kernel. It is in line
with the effort to make livepatching less and less error prone.

And please, let's stop playing this multi-user games. There is at least
one known user of source based livepatches. By coincidence, it is also
a big contributor to this subsystem. Adding an extra option into
CFLAGS is quite error prone. You can imagine how complicated is
a kernel rpm spec file for more kernel flavors. The only safe way
is to have the optimization tight with the CONFIG option in
kernel sources.


> 5) Fix the objtool warnings (or is it a GCC bug)

Nobody was aware of them. I wonder if they even existed at that time.
We have a simple fix now. Let's continue in the thread started by
Jikos if we could get a better solution.


> 6) Make -flive-patching compatible with LTO (or at least acknowledge
>    that it should and will be done soon)

Is LTO officially supported upstream?
Are all patches, features tested for LTO compactibility?
Is there any simple way to build and run LTO kernel?


> 7) At least make it build- or runtime-incompatible with Clang-built
>    kernels to prevent people from assuming it's safe.

Same questions as for LTO.


> If you don't want to revert the patch, then address my concerns instead
> of minimizing and deflecting at every opportunity.

I would really like to keep focusing on realistic problems and
realistic solutions:

   + make the optimization configurable if you resist on it
   + fix the objtool warnings

Anything else is out of scope of this thread from my POV.

Best Regards,
Petr

  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
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 [this message]
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 publically 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=20200130095346.6buhb3reehijbamz@pathway.suse.cz \
    --to=pmladek@suse.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=jpoimboe@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=nstange@suse.de \
    --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