On Fri, Jul 12, 2024 at 02:28:38PM +0200, Arnd Bergmann wrote:
On Fri, Jul 12, 2024, at 14:13, Naresh Kamboju wrote:
The 32-bit arm, mips and powerpc the tinyconfig builds failed on today's Linux next-20240712 tag with gcc and clang builds. The defconfig builds pass.
GOOD: next-20240711 BAD: next-20240712
Build error:
arm-linux-gnueabihf-ld: kernel/task_work.o: in function `task_work_add': task_work.c:(.text+0xc2): undefined reference to `irq_work_queue'
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
The call to this function was added in 466e4d801cd4 ("task_work: Add TWA_NMI_CURRENT as an additional notify mode."). It's possible
Thanks, that initial report was mostly useless without that sha. I do wonder why 0day build robot didn't complain to me about this. It seems something it should definitely find.
that we may have to always enable IRQ_WORK even on non-SMP kernels now. In practice it is already enabled in most configurations for one reason or another, the the cost is likely very small.
Otherwise checking for CONFIG_HAVE_NMI in the new code might work.
ARM seems to have HAVE_NMI while also being one of the architectures that is now failing.
I'm a bit confused though, perf is already depending on irq_work (and perf is the user of TWA_NMI_CURRENT). So I'm not exactly sure what config fail is leading to all this.
I suppose we can do something like the below.. it'll end up in a runtime fail for whoever manages to use TWA_NMI_CURRENT without also having irq_work enabled, but that should currently be nobody.
--- kernel/task_work.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/kernel/task_work.c b/kernel/task_work.c index 5c2daa7ad3f9..276e245b7e7e 100644 --- a/kernel/task_work.c +++ b/kernel/task_work.c @@ -81,9 +81,11 @@ int task_work_add(struct task_struct *task, struct callback_head *work, case TWA_SIGNAL_NO_IPI: __set_notify_signal(task); break; +#ifdef CONFIG_IRQ_WORK case TWA_NMI_CURRENT: irq_work_queue(this_cpu_ptr(&irq_work_NMI_resume)); break; +#endif default: WARN_ON_ONCE(1); break;