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>
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()
Date: Tue, 28 Jan 2020 16:40:46 +0100
Message-ID: <20200128154046.trkpkdaz7qeovhii@pathway.suse.cz> (raw)
In-Reply-To: <20200128150014.juaxfgivneiv6lje@treble>

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.

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.


> 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?


> 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. It is actually the only somehow
documented way. Sure, the documentation might get improved.
Patches are welcome.

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.
N-1 users are just waiting until the 1 user develops more helper
tools for this. I would really like to hear about some serious problems
before we do this step back in upstream.

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 [this message]
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 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=20200128154046.trkpkdaz7qeovhii@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=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