Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 8 Jun 2023 09:39:30 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Willy Tarreau <w@1wt.eu>
Cc:     Zhangjin Wu <falcon@tinylab.org>, thomas@t-8ch.de,
        linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: nolibc patches, still possible for 6.5 ?
Message-ID: <9dab59c7-a562-446d-94cf-39e4d40423c7@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <ZHyPi29q3MKiNAQZ@1wt.eu>
 <5494ac68-b4b9-434f-92c1-7e197c92a4ab@paulmck-laptop>
 <ZID0b+nIcypMjV0y@1wt.eu>
 <66c0e446-846c-47a6-ab60-948dc0118cec@paulmck-laptop>
 <ZIFa0Y7GIN0S/T6q@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZIFa0Y7GIN0S/T6q@1wt.eu>
Precedence: bulk

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