Re: nolibc patches, still possible for 6.5 ?

[Willy Tarreau]

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.

Thanks!
Willy