live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: David Laight <David.Laight@aculab.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"dvyukov@google.com" <dvyukov@google.com>,
	"seanjc@google.com" <seanjc@google.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"mbenes@suse.cz" <mbenes@suse.cz>,
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
	"linux-toolchains@vger.kernel.org"
	<linux-toolchains@vger.kernel.org>,
	live-patching@vger.kernel.org
Subject: Re: [PATCH 20/22] x86,word-at-a-time: Remove .fixup usage
Date: Fri, 12 Nov 2021 21:35:00 -0800	[thread overview]
Message-ID: <20211113053500.jcnx5airbn7g763a@treble> (raw)
In-Reply-To: <YY408BW0phe9I1/o@hirez.programming.kicks-ass.net>

On Fri, Nov 12, 2021 at 10:33:36AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 11, 2021 at 05:50:03PM -0800, Josh Poimboeuf wrote:
> 
> > Hm, I think there is actually a livepatch problem here.
> 
> I suspected as much, because I couldn't find any code dealing with it
> when I looked in a hurry.. :/
> 
> > Some ideas to fix:
> 
> > c) Update the reliable stacktrace code to mark the stack unreliable if
> >    it has a function with ".cold" in the name?
> 
> Why not simply match func.cold as func in the transition thing? Then
> func won't get patched as long as it (or it's .cold part) is in use.
> This seems like the natural thing to do.

Well yes, you're basically hinting at my first two options a and b:

a) Add a field to 'klp_func' which allows the patch module to specify a
   function's .cold counterpart?

b) Detect such cold counterparts in klp_enable_patch()?  Presumably it
   would require searching kallsyms for "<func>.cold", which is somewhat
   problematic as there might be duplicates.

It's basically a two-step process:  1) match func to .cold if it exists;
2) check for both in klp_check_stack_func().  The above two options are
proposals for the 1st step.  The 2nd step was implied.

I think something like that is probably the way to go, but the question
is where to match func to .cold:

  - patch creation;
  - klp_init_object_loaded(); or
  - klp_check_stack_func().

I think the main problem with matching them in the kernel is that you
can't disambiguate duplicate ".cold" symbols without disassembling the
function.  Duplicates are rare but they do exist.

Matching them at patch creation time (option a) may work best.  At least
with kpatch-build, the tooling already knows about .cold functions, so
explicitly matching them in new klp_func.{cold_name,cold_sympos} fields
would be trivial.

I don't know about other patch creation tooling, but I'd imagine they
also need to know about .cold functions, unless they have that
optimization disabled.  Because the func and its .cold counterpart
always need to be patched together.

-- 
Josh


  reply	other threads:[~2021-11-13  5:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20211105171821.654356149@infradead.org>
     [not found] ` <20211108164711.mr2cqdcvedin2lvx@treble>
     [not found]   ` <YYlshkTmf5zdvf1Q@hirez.programming.kicks-ass.net>
     [not found]     ` <CAKwvOdkFZ4PSN0GGmKMmoCrcp7_VVNjau_b0sNRm3MuqVi8yow@mail.gmail.com>
     [not found]       ` <YYov8SVHk/ZpFsUn@hirez.programming.kicks-ass.net>
     [not found]         ` <CAKwvOdn8yrRopXyfd299=SwZS9TAPfPj4apYgdCnzPb20knhbg@mail.gmail.com>
     [not found]           ` <20211109210736.GV174703@worktop.programming.kicks-ass.net>
     [not found]             ` <f6dbe42651e84278b44e44ed7d0ed74f@AcuMS.aculab.com>
     [not found]               ` <YYuogZ+2Dnjyj1ge@hirez.programming.kicks-ass.net>
     [not found]                 ` <2734a37ebed2432291345aaa8d9fd47e@AcuMS.aculab.com>
2021-11-12  1:50                   ` [PATCH 20/22] x86,word-at-a-time: Remove .fixup usage Josh Poimboeuf
2021-11-12  9:33                     ` Peter Zijlstra
2021-11-13  5:35                       ` Josh Poimboeuf [this message]
2021-11-15 12:36                         ` Miroslav Benes
2021-11-15 13:01                           ` Joe Lawrence
2021-11-15 23:40                             ` Josh Poimboeuf
2021-11-16  7:25                               ` Miroslav Benes
2021-11-15 12:59                         ` Miroslav Benes
2021-11-16 21:27                           ` Josh Poimboeuf
2021-11-18  7:15                             ` Miroslav Benes
2021-11-22 17:46                     ` Petr Mladek
2021-11-24 17:42                       ` Josh Poimboeuf
2021-11-25  8:18                         ` Petr Mladek

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=20211113053500.jcnx5airbn7g763a@treble \
    --to=jpoimboe@redhat.com \
    --cc=David.Laight@aculab.com \
    --cc=dvyukov@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=mbenes@suse.cz \
    --cc=morbo@google.com \
    --cc=ndesaulniers@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.com \
    --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
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).