On Thu, Mar 17, 2022 at 03:24:42PM +0000, Hyeonggon Yoo wrote: > On Thu, Mar 17, 2022 at 07:00:00AM -0700, Paul E. McKenney wrote: > > On Thu, Mar 17, 2022 at 11:32:53AM +0000, Hyeonggon Yoo wrote: > > > Hello RCU folks, > > > > > > I like to use minimal configuration for kernel development. > > > when building with tinyconfig + CONFIG_PREEMPT=y on arm64: > > > > > > ld: kernel/rcu/update.o: in function `call_rcu_tasks': > > > update.c:(.text+0xb2c): undefined reference to `irq_work_queue' > > > update.c:(.text+0xb2c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `irq_work_queue' > > > make: *** [Makefile:1155: vmlinux] Error 1 > > > > > > It seems RCU calls irq_work_queue() without checking if CONFIG_IRQ_WORK is enabled. > > > > Indeed it does! > > > > And kernel/rcu/Kconfig shows why: > > > > config TASKS_TRACE_RCU > > def_bool 0 > > select IRQ_WORK > > help > > This option enables a task-based RCU implementation that uses > > explicit rcu_read_lock_trace() read-side markers, and allows > > these readers to appear in the idle loop as well as on the CPU > > hotplug code paths. It can force IPIs on online CPUs, including > > idle ones, so use with caution. > > > > So the solution is to further minimize your configuration so as to > > deselect TASKS_TRACE_RCU. > > They are already not selected. Good, thank you. How about TASKS_RUDE_RCU, TASKS_TRACE_RCU, and TASKS_RCU_GENERIC? > > This means making sure that both BPF and > > the various RCU torture tests are all deselected. > > I wanted to say call_rcu_tasks() can be referenced even when IRQ_WORK is not > selected, making it fail to build. I am guessing because TASKS_RCU_GENERIC is selected? If so, does the patch at the end of this email help? > > > ld: kernel/rcu/update.o: in function `call_rcu_tasks': > > > update.c:(.text+0xb2c): undefined reference to `irq_work_queue' > > > update.c:(.text+0xb2c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `irq_work_queue' > > > make: *** [Makefile:1155: vmlinux] Error 1 > > Isn't it better to fix this build failure? But of course! However, first I need to know exactly what is causing your build failure. I cannot see your .config file, so I am having to guess. Don't get me wrong, I do have a lot of practice guessing, but it is still just guessing. ;-) > It fails to build when both TASKS_TRACE_RCU and IRQ_WORK are not selected > and PREEMPT is selected. > > │ Symbol: TASKS_TRACE_RCU [=n] │ > │ Type : bool │ > │ Defined at kernel/rcu/Kconfig:96 │ > │ Selects: IRQ_WORK [=n] │ > │ Selected by [n]: │ > │ - BPF_SYSCALL [=n] │ > │ - RCU_SCALE_TEST [=n] && DEBUG_KERNEL [=y] │ > │ - RCU_TORTURE_TEST [=n] && DEBUG_KERNEL [=y] │ > │ - RCU_REF_SCALE_TEST [=n] && DEBUG_KERNEL [=y] > > Thanks! > > > > > Or turn on IRQ_WORK, for example, if you need to use BPF. Or do you already have TASKS_RCU_GENERIC deselected? Thanx, Paul ------------------------------------------------------------------------ diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index bf8e341e75b4..f559870fbf8b 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -86,6 +86,7 @@ config TASKS_RCU config TASKS_RUDE_RCU def_bool 0 + select IRQ_WORK help This option enables a task-based RCU implementation that uses only context switch (including preemption) and user-mode
