From: "Jürgen Groß" <jgross@suse.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v3 2/3] x86/alternative: Use a helper function for patching alternatives
Date: Mon, 17 Nov 2025 15:45:05 +0100 [thread overview]
Message-ID: <dd6d1b4c-b474-4160-b160-5e4fa0805fdc@suse.com> (raw)
In-Reply-To: <20251117134146.GHaRsmGrON5UF7q2P8@fat_crate.local>
[-- Attachment #1.1.1: Type: text/plain, Size: 4051 bytes --]
On 17.11.25 14:41, Borislav Petkov wrote:
> On Mon, Nov 10, 2025 at 09:23:38AM +0100, Juergen Gross wrote:
>> +static void __init_or_module analyze_patch_site(struct patch_site *ps,
>> + struct alt_instr *p, struct alt_instr *end)
>> +{
>> + struct alt_instr *r;
>> + u8 buff_sz;
>> + u8 *repl;
>> +
>> + /*
>> + * In case of nested ALTERNATIVE()s the outer alternative might add
>> + * more padding. To ensure consistent patching find the max padding for
>> + * all alt_instr entries for this site (nested alternatives result in
>> + * consecutive entries).
>> + */
>> + ps->instr = instr_va(p);
>> + ps->len = p->instrlen;
>> + for (r = p+1; r < end && instr_va(r) == ps->instr; r++) {
>> + ps->len = max(ps->len, r->instrlen);
>> + p->instrlen = r->instrlen = ps->len;
>> + }
>> +
>> + BUG_ON(ps->len > sizeof(ps->buff));
>> + BUG_ON(p->cpuid >= (NCAPINTS + NBUGINTS) * 32);
>> +
>> + /*
>> + * Patch if either:
>> + * - feature is present
>> + * - feature not present but ALT_FLAG_NOT is set to mean,
>> + * patch if feature is *NOT* present.
>> + */
>> + if (!boot_cpu_has(p->cpuid) == !(p->flags & ALT_FLAG_NOT)) {
>> + memcpy(ps->buff, ps->instr, ps->len);
>> + return;
>> + }
>> +
>> + repl = (u8 *)&p->repl_offset + p->repl_offset;
>> + DPRINTK(ALT, "feat: %d*32+%d, old: (%pS (%px) len: %d), repl: (%px, len: %d) flags: 0x%x",
>> + p->cpuid >> 5, p->cpuid & 0x1f,
>> + ps->instr, ps->instr, ps->len,
>> + repl, p->replacementlen, p->flags);
>> +
>> + memcpy(ps->buff, repl, p->replacementlen);
>> + buff_sz = p->replacementlen;
>> +
>> + if (p->flags & ALT_FLAG_DIRECT_CALL)
>> + buff_sz = alt_replace_call(ps->instr, ps->buff, p);
>> +
>> + for (; buff_sz < ps->len; buff_sz++)
>> + ps->buff[buff_sz] = 0x90;
>> +
>> + __apply_relocation(ps->buff, ps->instr, ps->len, repl, p->replacementlen);
>> +
>> + DUMP_BYTES(ALT, ps->instr, ps->len, "%px: old_insn: ", ps->instr);
>> + DUMP_BYTES(ALT, repl, p->replacementlen, "%px: rpl_insn: ", repl);
>> + DUMP_BYTES(ALT, ps->buff, ps->len, "%px: final_insn: ", ps->instr);
>> +}
>
> Well, this doesn't quite look like what I suggested: if we have a function
> analyze_patch_site() then it should do only that - analyze the patch site
> *only* and not do the patching too.
It doesn't do the patching. That is done in the caller of
analyze_patch_site().
What it does do is looking at one patch site and putting the code to be
patched in into the temporary buffer and then it is printing the debug
info related to the result of the analysis.
> With the point being that struct patch_site should carry the necessary
> information between an analyze step and a patching step so that you have
> simple functions doing one thing and one thing only - not mix up things.
>
> And your 3rd patch is making things even worse again - simply in a different
> way.
It is following the same direction:
- analyze the patch site (now all of the alternatives for one location)
- putting the code to be patched into the buffer
- print the debug info related to that patch site
>
> So please take enough time to split the functionality:
>
> 1. one function does only patch sites analysis. Once it is done, the
> patch_site struct will contain *all* possible information for the next
> function:
>
> 2. patch site. This one takes the information gathered by the analysis phase
> and uses it to patch the site, fixup direct calls, apply relocations, dump
> debug info and so on.
The reason I was doing that way was to _really_ have the patching done only
once. This includes the case when the original instruction is kept and just
the nops are being optimized.
I can add one other layer doing the split you are asking for: one for gathering
the information and one for applying relocs and debug printing. But I'd really
like to keep the final patching in apply_alternatives(), as this makes it very
clear where the final patching of the code is done.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
next prev parent reply other threads:[~2025-11-17 14:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 8:23 [PATCH v3 0/3] x86/alternative: Patch a single alternative location only once Juergen Gross
2025-11-10 8:23 ` [PATCH v3 1/3] x86/alternative: Drop not needed test after call of alt_replace_call() Juergen Gross
2025-11-10 8:23 ` [PATCH v3 2/3] x86/alternative: Use a helper function for patching alternatives Juergen Gross
2025-11-17 13:41 ` Borislav Petkov
2025-11-17 14:45 ` Jürgen Groß [this message]
2025-11-18 15:09 ` Borislav Petkov
2025-11-10 8:23 ` [PATCH v3 3/3] x86/alternative: Patch a single alternative location only once Juergen Gross
2025-11-16 12:42 ` [PATCH v3 0/3] " Borislav Petkov
2025-11-17 11:26 ` Jürgen Groß
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=dd6d1b4c-b474-4160-b160-5e4fa0805fdc@suse.com \
--to=jgross@suse.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®