Re: [BUG 4.2-rc8] Interrupt occurs while apply_alternatives() is patching the handler

From: Thomas Gleixner
Date: Thu Sep 03 2015 - 06:42:48 EST


On Thu, 3 Sep 2015, Borislav Petkov wrote:
> On Wed, Sep 02, 2015 at 11:11:55AM +0200, Thomas Gleixner wrote:
> > static void __init_or_module add_nops(void *insns, unsigned int len)
> > {
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > while (len > 0) {
>
> I guess you want to optimize the len==0 case to not disable interrupts
> needlessly:
>
> if (!len)
> return;
>
> local_irq_save(flags);
> while (len > 0)
> ...

Nah. I rather put the local_irq_save into optimize_nops(). All other
callers of add_nops() are operating on a buffer and use text_poke
after that. Aside of that optimize_nops() is missing a sync_core().

Updated patch below.

Thanks,

tglx

----------------->
Subject: x86/alternatives: Make optimize_nops() interrupt safe and synced
From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Date: Thu, 03 Sep 2015 12:34:55 +0200

optimize_nops() is buggy in two aspects:

- It's not disabling interrupts across the modification
- It's lacking a sync_core() call

Fixes: 4fd4b6e5537c 'x86/alternatives: Use optimized NOPs for padding'
Reported-by: "Richard W.M. Jones" <rjones@xxxxxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
---
arch/x86/kernel/alternative.c | 5 +++++
1 file changed, 5 insertions(+)

Index: tip/arch/x86/kernel/alternative.c
===================================================================
--- tip.orig/arch/x86/kernel/alternative.c
+++ tip/arch/x86/kernel/alternative.c
@@ -338,10 +338,15 @@ done:

static void __init_or_module optimize_nops(struct alt_instr *a, u8 *instr)
{
+ unsigned long flags;
+
if (instr[0] != 0x90)
return;

+ local_irq_save(flags);
add_nops(instr + (a->instrlen - a->padlen), a->padlen);
+ sync_core();
+ local_irq_restore(flags);

DUMP_BYTES(instr, a->instrlen, "%p: [%d:%d) optimized NOPs: ",
instr, a->instrlen - a->padlen, a->padlen);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/