Re: [PATCH v9] kernel/fork: beware of __put_task_struct calling context

[Wander Lairson Costa]

On Fri, Jun 2, 2023 at 2:34 PM Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>
> On 06/01, Wander Lairson Costa wrote:
> >
> > On Thu, Jun 1, 2023 at 3:14 PM Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
> > >
> > > > but only in the RT kernel
> > >
> > > this again suggests that your testing was wrong or I am totally confused (quite
> > > possible, I know nothing about RT). I did the testing without CONFIG_PREEMPT_RT.
> > >
> >
> > Hrm, could you please share your .config?
>
> Sure. I do not want to spam the list, I'll send you a private email.
>

Thanks. I found an unrelated earlier splat in the console code. That's
why I couldn't reproduce it in the stock kernel.

> Can you share your kernel module code?
>

*facepalm* I forgot to post the link: https://github.com/walac/test-prove-lock/

> Did you verify that debug_locks != 0 as I asked in my previous email ?
>
> > > > But running the reproducer for put_task_struct(), works fine.
> > >
> > > which reproducer ?
> > >
> >
> > Only now I noticed I didn't add the reproducer to the commit message:
> >
> > while true; do
> >     stress-ng --sched deadline --sched-period 1000000000
> > --sched-runtime 800000000 --sched-deadline 1000000000 --mmapfork 23 -t
> > 20
> > done
>
> Cough ;) I think we need a more simple one to enssure that
> refcount_sub_and_test(nr, &t->usage) returns true under raw_spin_lock()
> and then __put_task_struct() actually takes spin_lock().
>
> Oleg.
>