[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9dab59c7-a562-446d-94cf-39e4d40423c7@paulmck-laptop>
Date: Thu, 8 Jun 2023 09:39:30 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Willy Tarreau <w@....eu>
Cc: Zhangjin Wu <falcon@...ylab.org>, thomas@...ch.de,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: nolibc patches, still possible for 6.5 ?
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
Powered by blists - more mailing lists