Messages in this thread | | | From | Wander Lairson Costa <> | Date | Mon, 5 Jun 2023 08:24:13 -0300 | Subject | Re: [PATCH v9] kernel/fork: beware of __put_task_struct calling context |
| |
On Fri, Jun 2, 2023 at 2:34 PM Oleg Nesterov <oleg@redhat.com> wrote: > > On 06/01, Wander Lairson Costa wrote: > > > > On Thu, Jun 1, 2023 at 3:14 PM Oleg Nesterov <oleg@redhat.com> 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. >
| |