From: Peter Zijlstra <firstname.lastname@example.org> To: Petr Mladek <email@example.com> Cc: Josh Poimboeuf <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH v4 15/16] module: Move where we mark modules RO,X Date: Fri, 25 Oct 2019 10:43:00 +0200 Message-ID: <20191025084300.GG4131@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, Oct 25, 2019 at 08:44:56AM +0200, Petr Mladek wrote: > On Thu 2019-10-24 15:16:34, Peter Zijlstra wrote: > > On Wed, Oct 23, 2019 at 12:00:25PM -0500, Josh Poimboeuf wrote: > > > > > > This then raises a number of questions: > > > > > > > > 1) why is that RELA (that obviously does not depend on any module) > > > > applied so late? > > > > > > Good question. The 'pv_ops' symbol is exported by the core kernel, so I > > > can't see any reason why we'd need to apply that rela late. In theory, > > > kpatch-build isn't supposed to convert that to a klp rela. Maybe > > > something went wrong in the patch creation code. > > > > > > I'm also questioning why we even need to apply the parainstructions > > > section late. Maybe we can remove that apply_paravirt() call > > > altogether, along with .klp.arch.parainstruction sections. > > Hmm, the original bug report against livepatching was actually about > paravirt ops, see below. Yes, I found that. > > > I'm not sure about alternatives, but maybe we can enforce such > > > limitations with tooling and/or kernel checks. > > > > Right, so on IRC you implied you might have some additional details on > > how alternatives were affected; did you manage to dig that up? > > I am not sure what Josh had in mind. But the problem with livepatches, > paravort ops, and alternatives was described in the related patchset, see > https://email@example.com Yes, and my complaint there is that that thread is void of useful content. > The original bug report is > https://lkml.kernel.org/r/20160329120518.GA21252@canonical.com I found the github (*groan*) link in the thread above. From all that I could only make that the paravirt stuff is just doing it wrong (see earlier emails, core-kernel RELAs really should be applied at the time of patch-module load, there's no excuse for them to be delayed to the .klp.rela. section) at which point paravirt will also magically work. But none of that explains why apply_alternatives() is also delayed. So I'm very tempted to just revert that patchset for doing it all wrong.
next prev parent reply index Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> [not found] ` <email@example.com> [not found] ` <20191021135312.jbbxsuipxldocdjk@treble> [not found] ` <20191021141402.GI1817@hirez.programming.kicks-ass.net> [not found] ` <20191023114835.GT1817@hirez.programming.kicks-ass.net> 2019-10-23 17:00 ` Josh Poimboeuf 2019-10-24 13:16 ` Peter Zijlstra 2019-10-25 6:44 ` Petr Mladek 2019-10-25 8:43 ` Peter Zijlstra [this message] 2019-10-25 10:06 ` Peter Zijlstra 2019-10-25 13:50 ` Josh Poimboeuf 2019-10-26 1:17 ` Josh Poimboeuf 2019-10-28 10:07 ` Peter Zijlstra 2019-10-28 10:43 ` Peter Zijlstra 2019-10-25 9:16 ` Peter Zijlstra
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=20191025084300.GG4131@hirez.programming.kicks-ass.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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 \ firstname.lastname@example.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