From: John Keeping <john@metanate.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>,
linux-rt-users@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RT] BUG in sched/cpupri.c
Date: Wed, 22 Dec 2021 18:45:33 +0000 [thread overview]
Message-ID: <20211222184533.4c14868c.john@metanate.com> (raw)
In-Reply-To: <31a47e99-6de3-76ec-62ad-9c98d092ead5@arm.com>
On Wed, 22 Dec 2021 18:46:57 +0100
Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
> On 21.12.21 17:45, John Keeping wrote:
> > On Tue, 21 Dec 2021 16:11:34 +0000
> > Valentin Schneider <valentin.schneider@arm.com> wrote:
> >
> >> On 20/12/21 18:35, Dietmar Eggemann wrote:
>
> [...]
>
> >> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> >> index fd7c4f972aaf..7d61ceec1a3b 100644
> >> --- a/kernel/sched/deadline.c
> >> +++ b/kernel/sched/deadline.c
> >> @@ -2467,10 +2467,13 @@ static void switched_from_dl(struct rq *rq, struct task_struct *p)
> >> * this is the right place to try to pull some other one
> >> * from an overloaded CPU, if any.
> >> */
> >> - if (!task_on_rq_queued(p) || rq->dl.dl_nr_running)
> >> + if (!task_on_rq_queued(p))
> >> return;
> >>
> >> - deadline_queue_pull_task(rq);
> >> + if (!rq->dl.dl_nr_running)
> >> + deadline_queue_pull_task(rq);
> >> + else if (task_current(rq, p) && (p->sched_class < &dl_sched_class))
> >> + resched_curr(rq);
> >> }
> >>
> >> /*
> >> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> >> index ef8228d19382..1ea2567612fb 100644
> >> --- a/kernel/sched/rt.c
> >> +++ b/kernel/sched/rt.c
> >> @@ -2322,10 +2322,13 @@ static void switched_from_rt(struct rq *rq, struct task_struct *p)
> >> * we may need to handle the pulling of RT tasks
> >> * now.
> >> */
> >> - if (!task_on_rq_queued(p) || rq->rt.rt_nr_running)
> >> + if (!task_on_rq_queued(p))
> >> return;
> >>
> >> - rt_queue_pull_task(rq);
> >> + if (!rq->rt.rt_nr_running)
> >> + rt_queue_pull_task(rq);
> >> + else if (task_current(rq, p) && (p->sched_class < &rt_sched_class))
> >> + resched_curr(rq);
>
> switched_from_rt() -> rt_queue_pull_task(, pull_rt_task)
> pull_rt_task()->tell_cpu_to_push()->irq_work_queue_on(&rq->rd->rto_push_work,)
> rto_push_irq_work_func() -> push_rt_task(rq, true)
>
> seems to be the only way with pull=true.
>
> In my tests, rq->rt.rt_nr_running seems to be 0 when it happens.
>
> [ 22.288537] CPU3 switched_to_rt: p=[ksoftirqd/3 35]
> [ 22.288554] rt_mutex_setprio: CPU3 p=[ksoftirqd/3 35] pi_task=[rcu_preempt 11] queued=1 running=0 prio=98 oldprio=120
> [ 22.288636] CPU3 switched_from_rt: p=[ksoftirqd/3 35] rq->rt.rt_nr_running=0
> ^^^^^^^^^^^^^^^^^^^^^^
> [ 22.288649] rt_mutex_setprio: CPU3 p=[ksoftirqd/3 35] queued=1 running=1 prio=120 oldprio=98
> [ 22.288681] CPU3 push_rt_task: next_task=[rcu_preempt 11] migr_dis=1 rq->curr=[ksoftirqd/3 35] pull=1
> ^^^^^^^^^^ ^^^^^^
> [ 22.288698] CPU: 3 PID: 35 Comm: ksoftirqd/3 Not tainted 5.15.10-rt24-dirty #36
> [ 22.288711] Hardware name: ARM Juno development board (r0) (DT)
> [ 22.288718] Call trace:
> [ 22.288722] dump_backtrace+0x0/0x1ac
> [ 22.288747] show_stack+0x1c/0x70
> [ 22.288763] dump_stack_lvl+0x68/0x84
> [ 22.288777] dump_stack+0x1c/0x38
> [ 22.288788] push_rt_task.part.0+0x364/0x370
> [ 22.288805] rto_push_irq_work_func+0x180/0x190
> [ 22.288821] irq_work_single+0x34/0xa0
> [ 22.288836] flush_smp_call_function_queue+0x138/0x244
> [ 22.288852] generic_smp_call_function_single_interrupt+0x18/0x24
> [ 22.288867] ipi_handler+0xb0/0x15c
> ...
>
> What about slightly changing the layout in switched_from_rt() (only lightly tested):
I still see the BUG splat with the patch below applied :-(
> @@ -2322,7 +2338,15 @@ static void switched_from_rt(struct rq *rq, struct task_struct *p)
> * we may need to handle the pulling of RT tasks
> * now.
> */
> - if (!task_on_rq_queued(p) || rq->rt.rt_nr_running)
> + if (!task_on_rq_queued(p))
> + return;
> +
> + if (task_current(rq, p) && (p->sched_class < &rt_sched_class)) {
> + resched_curr(rq);
> + return;
> + }
> +
> + if (rq->rt.rt_nr_running)
> return;
>
> rt_queue_pull_task(rq);
next prev parent reply other threads:[~2021-12-22 18:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-18 14:25 [RT] BUG in sched/cpupri.c John Keeping
2021-12-20 17:35 ` Dietmar Eggemann
2021-12-21 16:11 ` Valentin Schneider
2021-12-21 16:45 ` John Keeping
2021-12-21 17:22 ` Valentin Schneider
2021-12-21 17:42 ` John Keeping
2021-12-22 17:46 ` Dietmar Eggemann
2021-12-22 18:45 ` John Keeping [this message]
2021-12-22 19:48 ` Valentin Schneider
2021-12-23 11:58 ` John Keeping
2021-12-23 14:05 ` Valentin Schneider
2022-01-07 10:46 ` Dietmar Eggemann
2022-01-07 11:49 ` John Keeping
2022-01-07 14:25 ` Dietmar Eggemann
2022-01-07 18:35 ` John Keeping
2022-01-14 18:25 ` Valentin Schneider
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211222184533.4c14868c.john@metanate.com \
--to=john@metanate.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).