Re: nolibc patches, still possible for 6.5 ?

[Willy Tarreau <w@1wt.eu>]

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.

> 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