Re: nolibc patches, still possible for 6.5 ?

[Paul E. McKenney]

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