Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1280798 > unrolled thread

Re: [PATCH v3] sched/deadline: fix earliest_dl.next logic

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3] sched/deadline: fix earliest_dl.next logic Juri Lelli <juri.lelli@arm.com> - 2015-12-01 12:40 +0100
    Re: [PATCH v3] sched/deadline: fix earliest_dl.next logic Wanpeng Li <kernellwp@gmail.com> - 2015-12-01 13:20 +0100

#1280798 — Re: [PATCH v3] sched/deadline: fix earliest_dl.next logic

On 30/11/15 10:20, Wanpeng Li wrote:
> 2015-11-27 20:14 GMT+08:00 Luca Abeni <luca.abeni@unitn.it>:
> > Hi all,
> >
> > I ran some quick tests on this patch (because I was working on something
> > related), and it seems to me that it triggers a bug. Here are some
> > information:

[snip]

> >
> > Here is my understanding of the crash:
> > - schedule() invokes pick_next_task_dl() which wants to do a context switch
> > (by selecting
> >   for execution a new task "p" which is different from "prev")
> > - pick_next_task_dl() invokes put_prev, which puts the "prev" task in the
> > pushable tasks
> >   queue (WARNING! "prev" is still the "current" task in this rq, because the
> > scheduler is
> >   still running... I think this is the source of the issue)
> > - then, pick_next_task_dl() invokes dequeue_pushable_dl_task() on p, to
> > remove the selected
> >   task from the pushable tasks queue...
> > - ...But after your patch dequeue_pushable_dl_task() invokes
> > pick_next_pushable_dl_task().
> >   Which sees that the next pushable task is the "current" task (see above).
> > This happens
> >   becuase "prev" has already been inserted in the pushable tasks queue, and
> > can be the
> >   next pushable task... But "current" has not been updated yet.
> > - The BUG_ON() at line 1443 of deadline.c is just "BUG_ON(task_current(rq,
> > p))"
> 
> Thanks for your report and great analyse, Luca, you are right.
> 
> >
> > Summing up, I think pick_next_pushable_dl_task() cannot be called from
> > dequeue_pushable_dl_task() (at least, not without removing or modifying that
> > BUG_ON()).
> 
> Juri, how about remove this BUG_ON() just like rt class?
> 

It seems that we actually check the very same conditions for RT, as we
do for DL. The difference is that RT doesn't call pick_next_pushable
_task(). I think we can do the same, just checking and eventually using
the updated leftmost in dequeue_pushable_dl_task().

Thanks,

- Juri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1280815

2015-12-01 19:30 GMT+08:00 Juri Lelli <juri.lelli@arm.com>:
> On 30/11/15 10:20, Wanpeng Li wrote:
>> 2015-11-27 20:14 GMT+08:00 Luca Abeni <luca.abeni@unitn.it>:
>> > Hi all,
>> >
>> > I ran some quick tests on this patch (because I was working on something
>> > related), and it seems to me that it triggers a bug. Here are some
>> > information:
>
> [snip]
>
>> >
>> > Here is my understanding of the crash:
>> > - schedule() invokes pick_next_task_dl() which wants to do a context switch
>> > (by selecting
>> >   for execution a new task "p" which is different from "prev")
>> > - pick_next_task_dl() invokes put_prev, which puts the "prev" task in the
>> > pushable tasks
>> >   queue (WARNING! "prev" is still the "current" task in this rq, because the
>> > scheduler is
>> >   still running... I think this is the source of the issue)
>> > - then, pick_next_task_dl() invokes dequeue_pushable_dl_task() on p, to
>> > remove the selected
>> >   task from the pushable tasks queue...
>> > - ...But after your patch dequeue_pushable_dl_task() invokes
>> > pick_next_pushable_dl_task().
>> >   Which sees that the next pushable task is the "current" task (see above).
>> > This happens
>> >   becuase "prev" has already been inserted in the pushable tasks queue, and
>> > can be the
>> >   next pushable task... But "current" has not been updated yet.
>> > - The BUG_ON() at line 1443 of deadline.c is just "BUG_ON(task_current(rq,
>> > p))"
>>
>> Thanks for your report and great analyse, Luca, you are right.
>>
>> >
>> > Summing up, I think pick_next_pushable_dl_task() cannot be called from
>> > dequeue_pushable_dl_task() (at least, not without removing or modifying that
>> > BUG_ON()).
>>
>> Juri, how about remove this BUG_ON() just like rt class?
>>
>
> It seems that we actually check the very same conditions for RT, as we
> do for DL. The difference is that RT doesn't call pick_next_pushable
> _task(). I think we can do the same, just checking and eventually using
> the updated leftmost in dequeue_pushable_dl_task().

Thanks for your suggestion, just send out v4.

Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web