Re: [PATCH 1/7] stop_machine: Introduce stop_machine_nmi()

[Chang S. Bae]

On 1/27/2026 6:49 AM, Borislav Petkov wrote:
> > > > vmlinux.o: error: objtool: stop_machine_nmi_handler+0x23: call to {dynamic}() leaves .noinstr.text section
>
> This one would be hard to fix because that's the
>
> 	err = msdata->fn(msdata->data);
>
> function pointer which objtool can't see through.

Yes. Under certain config, the 0-day bot tirggers this with 
CONFIG_NOINSTR_VALIDATION=y.

Objtool ends up with the following path:

tools/objtool/check.c::validation_call()
-> noinstr_call_dest()
   {
	/*
	 * We can't deal with indirect function calls at present;
	 * assume they're instrumented.
	 */
	if (!func) {
		if (file->pv_ops)
			return pv_call_dest(file, insn);

		return false;
	}
    ...
   }

So every indirect call under noinstr is conservatively treated as 
invalid except for pv_ops which seems to be investigated further. In 
this series, however, the destination code is to in .noinstr.text.

Given this, I considered something to be adjusted on the tool side, e.g. 
by whitelisting the case along the lines of

  if (!func) {
    ...

    if (!strncmp(insn_func(insn)->name, "stop_machine_nmi_handler", 24))
      return true;

    return false;
  }

The existing pv_ops handling also looks somewhat misaligned with large 
objects like vmlinux.o.

> So my suggestion would be to do:
>
> struct nmi_multi_stop_data {
> 	cpu_stop_safe_fn_t           fn;
>
> note the different function pointer type which we will hopefully catch during
> review in the sense that only *safe* functions should be callable by the
> NMI-specific stomp_machine.
>
> Along with:
>
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index 189b4b108d13..55a350048d4c 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -230,7 +230,9 @@ bool noinstr stop_machine_nmi_handler(void)
>   	raw_cpu_write(stop_machine_nmi_ctrl.nmi_enabled, false);
>   
>   	msdata = raw_cpu_read(stop_machine_nmi_ctrl.msdata);
> +	instrumentation_begin();
>   	err = msdata->fn(msdata->data);
> +	instrumentation_end();
>   	raw_cpu_write(stop_machine_nmi_ctrl.err, err);
>   	return true;
>   }

I also thought this change, but I was a bit hesitant as it could be seen 
as lifting up the no-instrumentation.

Now I suppose the net effect will be the same with other workaround, 
e.g. tool-side whitelisting. So I think I can go with this as you 
suggested (with a clear note on this).

> ofc.
>
> Unless someone has a better idea ofc...

Sure.

Thanks,
Chang