Re: nolibc patches, still possible for 6.5 ?

[Paul E. McKenney]

On Thu, Jun 08, 2023 at 10:21:57AM +0200, Willy Tarreau wrote:
> Hi Zhangjin,
> 
> On Thu, Jun 08, 2023 at 04:13:37PM +0800, Zhangjin Wu wrote:
> > > 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.
> > >
> > 
> > Sorry, The reason is that to speed up the kernel build+nolibc tests, a
> > local small config was customized for the first report,
> 
> You don't have to be sorry for this! The more diversity in configs, the
> more bugs are discovered before they hit users.

And I couldn't agree more!  Again, thank you both!

							Thanx, Paul

> > it may not
> > trigger the above issue, in the later report about the v4 rv32 compile
> > support [1], I did test 'run' target with the default defconfig and
> > reported the same failure as bove, this is the note I pasted there:
> > 
> >   ---
> >   Did compile test for aarch64, rv32 and rv64, include run-user and run.
> > 
> >   Note, this is required with the default config from the
> >   20230606-nolibc-rv32+stkp7a branch of [5]:
> > 
> >     diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> >     index ce02bb09651b..72bd8fe0cad6 100644
> >     --- a/kernel/rcu/tasks.h
> >     +++ b/kernel/rcu/tasks.h
> >     @@ -1934,11 +1934,13 @@ void show_rcu_tasks_gp_kthreads(void)
> >      }
> >      #endif /* #ifndef CONFIG_TINY_RCU */
> > 
> >     +#ifdef CONFIG_TASKS_RCU
> >      struct task_struct *get_rcu_tasks_gp_kthread(void)
> >      {
> >             return rcu_tasks.kthread_ptr;
> >      }
> >      EXPORT_SYMBOL_GPL(get_rcu_tasks_gp_kthread);
> >     +#endif
> > 
> >      #ifdef CONFIG_PROVE_RCU
> >      struct rcu_tasks_test_desc {
> >   ---
> 
> Indeed, I initially didn't make the connection regarding this, because
> you mentioned the fix but not the problem, so I didn't remember to take
> any particular care about this.
> 
> > I have seen Paul have known the cause of the above issue in your later
> > discussion and you found a better solution to avoid such failures,
> > congrats!
> 
> Yes apparently Paul is aware of it so that's all what I wanted to make
> sure of.
> 
> Thanks!
> Willy
> 
> PS: I'll hopefully check your other series later today