All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Perret <qperret@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>,
	linux-kernel@vger.kernel.org, aaron.lwe@gmail.com,
	valentin.schneider@arm.com, mingo@kernel.org, pauld@redhat.com,
	jdesfossez@digitalocean.com, naravamudan@digitalocean.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	juri.lelli@redhat.com, rostedt@goodmis.org, bsegall@google.com,
	mgorman@suse.de, kernel-team@android.com, john.stultz@linaro.org
Subject: Re: NULL pointer dereference in pick_next_task_fair
Date: Thu, 7 Nov 2019 19:27:53 +0000	[thread overview]
Message-ID: <20191107192753.GA55494@google.com> (raw)
In-Reply-To: <20191107184356.GF4114@hirez.programming.kicks-ass.net>

On Thursday 07 Nov 2019 at 19:43:56 (+0100), Peter Zijlstra wrote:
> But you mean something like:
> 
> 	for (class = prev->sched_class; class; class = class->next) {
> 		if (class->balance(rq, rf))
> 			break;
> 	}
> 
> 	put_prev_task(rq, prev);
> 
> 	for_each_class(class) {
> 		p = class->pick_next_task(rq);
> 		if (p)
> 			return p;
> 	}
> 
> 	BUG();
> 
> like?

Right, something like that, though what I had was basically doing the
pull from within the pick_next_task_*() functions directly, like we were
doing before. I'm now seeing how easy it is to get this wrong, and that
even good-looking code in this area can be broken in very subtle ways,
so I didn't feel comfortable refactoring again so close to rc7. If you
feel more confident, I'm more than happy to test a patch implemeting the
above :)

> I had convinced myself we didn't need that, but that DL to RT case is
> pesky and might require it after all.

Yep, I don't see a way to avoid iterating all classes to do the balance,
one way or another ...

Thanks,
Quentin

  reply	other threads:[~2019-11-07 19:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 17:46 NULL pointer dereference in pick_next_task_fair Quentin Perret
2019-10-28 21:49 ` Peter Zijlstra
2019-10-29 11:34 ` Peter Zijlstra
2019-10-29 11:50   ` Quentin Perret
2019-10-30 22:50     ` Ram Muthiah
2019-10-31  1:33       ` Valentin Schneider
2019-10-31 10:54         ` Valentin Schneider
2019-10-31 14:24           ` Valentin Schneider
2019-10-31 22:15       ` Valentin Schneider
2019-11-06 12:05 ` Peter Zijlstra
2019-11-06 13:08   ` Peter Zijlstra
2019-11-06 15:04     ` Qais Yousef
2019-11-06 16:57       ` Peter Zijlstra
2019-11-06 17:26         ` Qais Yousef
2019-11-06 15:51   ` Kirill Tkhai
2019-11-06 16:54     ` Peter Zijlstra
2019-11-06 17:27       ` Peter Zijlstra
2019-11-07  8:36         ` Kirill Tkhai
2019-11-07 13:26           ` Peter Zijlstra
2019-11-07 15:12             ` Kirill Tkhai
2019-11-07 15:42               ` Peter Zijlstra
2019-11-07 15:53                 ` Kirill Tkhai
2019-11-07 15:38             ` Quentin Perret
2019-11-07 18:43               ` Peter Zijlstra
2019-11-07 19:27                 ` Quentin Perret [this message]
2019-11-07 19:31                   ` Peter Zijlstra
2019-11-07 19:42                     ` Quentin Perret
2019-11-07 19:29                 ` Peter Zijlstra
2019-11-08 11:02                   ` Quentin Perret
2019-11-08 11:47                     ` Valentin Schneider
2019-11-08 11:58                       ` Quentin Perret
2019-11-08 12:00                     ` Peter Zijlstra
2019-11-08 12:15                       ` Quentin Perret
2019-11-08 12:35                         ` Peter Zijlstra
2019-11-08 12:24                       ` Peter Zijlstra
2019-11-08 11:55                   ` Peter Zijlstra
2019-11-08 12:52                     ` Peter Zijlstra
2019-11-07 16:09             ` Qais Yousef

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=20191107192753.GA55494@google.com \
    --to=qperret@google.com \
    --cc=aaron.lwe@gmail.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=jdesfossez@digitalocean.com \
    --cc=john.stultz@linaro.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@android.com \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=naravamudan@digitalocean.com \
    --cc=pauld@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.