Live-Patching Archive on lore.kernel.org
 help / color / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.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>
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()
Date: Tue, 28 Jan 2020 11:02:54 -0600
Message-ID: <20200128170254.igb72ib5n7lvn3ds@treble> (raw)
In-Reply-To: <20200128154046.trkpkdaz7qeovhii@pathway.suse.cz>

On Tue, Jan 28, 2020 at 04:40:46PM +0100, Petr Mladek wrote:
> On Tue 2020-01-28 09:00:14, Josh Poimboeuf wrote:
> > On Tue, Jan 28, 2020 at 10:28:07AM +0100, Miroslav Benes wrote:
> > > I don't think we have something special at SUSE not generally available...
> > > 
> > > ...and I don't think it is really important to discuss that and replying 
> > > to the above, because there is a legitimate use case which relies on the 
> > > flag. We decided to support different use cases right at the beginning.
> > > 
> > > I understand it currently complicates things for objtool, but objtool is 
> > > sensitive to GCC code generation by definition. "Issues" appear with every 
> > > new GCC version. I see no difference here and luckily it is not so 
> > > difficult to fix it.
> > > 
> > > I am happy to help with acting on those objtool warning reports you 
> > > mentioned in the other email. Just Cc me where appropriate. We will take a 
> > > look.
> > 
> > As I said, the objtool warnings aren't even the main issue.
> 
> Great.
> 
> Anyway, I think that we might make your life easier with using
> the proposed -Wsuggest-attribute=noreturn.

Maybe.  Though if I understand correctly, this doesn't help for any of
the new warnings because they're for static functions, and this only
warns about global functions.

> Also it might be possible to create the list of global
> noreturn functions using some gcc tool. Similar way that we get
> the list of functions that need to be livepatched explicitly
> because of the problematic optimizations.
> 
> It sounds like a win-win approach.

I don't quite get how that could be done in an automated way, but ideas
about how to implement it would certainly be welcome.

> > There are N users[*] of CONFIG_LIVEPATCH, where N is perhaps dozens.
> > For N-1 users, they have to suffer ALL the drawbacks, with NONE of the
> > benefits.
> 
> You wrote in the other mail:
> 
>   > The problems associated with it: performance, LTO incompatibility,
>   > clang incompatibility (I think?), the GCC dead code issue.
> 
> SUSE performance team did extensive testing and did not found
> any real performance issues. It was discussed when the option
> was enabled upstream.
> 
> Are the other problems affecting real life usage, please?
> Could you be more specific about them, please?

The original commit mentioned 1-3% scheduler degradation.  And I'd
expect things to worsen over time as interprocedural optimizations
improve.

Also, LTO is coming whether we like it or not.  As is Clang.  Those are
real-world things which will need to work with livepatching sooner or
later.

> > And, even if they wanted those benefits, they have no idea how to get
> > them because the patch creation process isn't documented.
> 
> I do not understand this. All the sample modules and selftests are
> using source based livepatches.

We're talking in circles.  Have you read the thread?

The samples are a (dangerous) joke.  With or without -flive-patching.

> It is actually the only somehow documented way. Sure, the
> documentation might get improved.  Patches are welcome.

Are you suggesting for *me* to send documentation for how *you* build
patches?

> The option is not currently needed by the selftests only because there
> is no selftest for this type of problems. But the problems are real.
> They would actually deserve selftests. Again, patches are welcome.
> 
> My understanding is that the source based livepatches is the future.

I think that still remains to be seen.

> N-1 users are just waiting until the 1 user develops more helper tools
> for this.

No.  N-1 users have no idea how to make (safe) source-based patches in
the first place.  And if *you* don't need the tools, why would anyone
else?  Why not document the process and encourage the existence of other
users so they can get involved and help with the tooling?

> I would really like to hear about some serious problems
> before we do this step back in upstream.

Sometimes you need to take 1 step back before you can take 2 steps
forward.  I regret ACKing the original patch.  It was too early.

-- 
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
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 [this message]
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=20200128170254.igb72ib5n7lvn3ds@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=pmladek@suse.com \
    --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