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
