On Thu, Jun 08, 2023 at 06:36:33AM +0200, Willy Tarreau wrote:
On Wed, Jun 07, 2023 at 03:58:01PM -0700, Paul E. McKenney wrote:
Regarding the build failure affecting s390x and riscv64, it's a regular kernel resulting from "make defconfig". For both archs, I'm getting this failure:
In file included from kernel/rcu/update.c:649: kernel/rcu/tasks.h: In function 'get_rcu_tasks_gp_kthread': CC fs/kernfs/dir.o CC security/bpf/hooks.o kernel/rcu/tasks.h:1939:16: error: 'rcu_tasks' undeclared (first use in this function) 1939 | return rcu_tasks.kthread_ptr; | ^~~~~~~~~ kernel/rcu/tasks.h:1939:16: note: each undeclared identifier is reported only once for each function it appears in kernel/rcu/tasks.h:1940:1: error: control reaches end of non-void function [-Werror=return-type] 1940 | } | ^ cc1: some warnings being treated as errors
I rebased the branch on top of 6.4-rc5 and got the same. I'm building with gcc-11.3.0 from kernel.org. I'm not sure whether this comes from my build environment or recent changes to the kernel, but I'm sure I haven't seen that error during 6.3-rc cycle. However, given that Zhangjin seems to have successfully built it for riscv, there might be something odd on my side.
That line of code is in rcu/dev but not in mainline yet. In fact, it is not yet in -next.
But it is a bug. One that my Kconfig laziness hid from me. Easy fix, but it is clearly time for me to stop being lazy about that part of the Kconfig setup. :-/
So thank you for reporting it!
Great, I'm happy that it cuold be used to spot a real bug ;-)
Longer term, both to avoid you having to deal with RCU bugs and to make it easier to have multiple administrative nolibc maintainers, it might work better for you to base your stack on vX.y-rc1. That way, I could just pull directly from your tree.
(...)
This is something to think about for some upcoming cycle, given that we are already pretty much set up for the upcoming merge window.
Yes I think it makes sense now. Initially tiny changes had implications on rcutorture and needed to be properly sequenced but that's no longer the case and we can indeed simplify this. And it will force us to gather all patches in one single series, which is also easier to review/discuss.
So that works for me.
Very good!
Actually, in theory, I could replace my current stack with a direct pull of your stack and get a head start on this process. Let me see how I feel about making this switch on Monday. ;-)
Thanx, Paul