LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: CFS related question
Date: Mon, 20 Oct 2008 22:20:38 +0400 [thread overview]
Message-ID: <20081020182038.GB503@localhost> (raw)
In-Reply-To: <48FCCA14.5000103@ct.jp.nec.com>
[Hiroshi Shimamoto - Mon, Oct 20, 2008 at 11:12:36AM -0700]
| Peter Zijlstra wrote:
| > On Sun, 2008-10-19 at 00:03 +0400, Cyrill Gorcunov wrote:
| >> Hi Ingo, Peter,
| >>
| >> I just curious, look we have the following
| >>
| >> static struct sched_entity *pick_next_entity(struct cfs_rq *cfs_rq)
| >> {
| >> struct sched_entity *se = NULL;
| >>
| >> if (first_fair(cfs_rq)) {
| >> se = __pick_next_entity(cfs_rq);
| >> se = pick_next(cfs_rq, se);
| >> set_next_entity(cfs_rq, se);
| >> }
| >>
| >> return se;
| >> }
| >>
| >> which I presume may return NULL so the following piece
| >> could fail
| >>
| >> static struct task_struct *pick_next_task_fair(struct rq *rq)
| >> {
| >> struct task_struct *p;
| >> struct cfs_rq *cfs_rq = &rq->cfs;
| >> struct sched_entity *se;
| >>
| >> if (unlikely(!cfs_rq->nr_running))
| >> return NULL;
| >>
| >> do {
| >> --> se = pick_next_entity(cfs_rq);
| >> --> OOPs cfs_rq = group_cfs_rq(se);
| >> } while (cfs_rq);
| >>
| >> p = task_of(se);
| >> hrtick_start_fair(rq, p);
| >>
| >> return p;
| >> }
| >>
| >> Did I miss something? Or it comepletely can NOT happen?
| >
| > pick_next_entity() only returns NULL when !first_fair(), which is when !
| > nr_running.
| >
| > So the initial !nr_running check in pick_next_task_fair() will catch
| > that. Further nested RQs will never have !nr_running because then they
| > get dequeued.
|
| Hi Peter,
|
| pick_next_entity() is used in pick_next_task_fair() only.
| So, checking first_fair() never fail, and if fails it means bug. Right?
|
| How about the below patch?
| --------
| From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
| Subject: [PATCH] sched: replace check with BUG_ON in pick_next_entity()
|
| BUG_ON instead of returning NULL in pick_next_entity() when !first_fair().
| Basically first_fair() is always true, and returning NULL will cause oops later.
|
| Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
| ---
| kernel/sched_fair.c | 12 ++++++------
| 1 files changed, 6 insertions(+), 6 deletions(-)
|
| diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
| index 9573c33..3ce7c25 100644
| --- a/kernel/sched_fair.c
| +++ b/kernel/sched_fair.c
| @@ -758,13 +758,13 @@ pick_next(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
| static struct sched_entity *pick_next_entity(struct cfs_rq *cfs_rq)
| {
| - struct sched_entity *se = NULL;
| + struct sched_entity *se;
|
| - if (first_fair(cfs_rq)) {
| - se = __pick_next_entity(cfs_rq);
| - se = pick_next(cfs_rq, se);
| - set_next_entity(cfs_rq, se);
| - }
| + BUG_ON(!first_fair(cfs_rq));
| +
| + se = __pick_next_entity(cfs_rq);
| + se = pick_next(cfs_rq, se);
| + set_next_entity(cfs_rq, se);
|
| return se;
| }
| --
| 1.5.6
|
Technically it should not happen (as Peter explained). But it
seems it happens sometime -- and most probably 'cause of error
in another part of kernel (ie indirect error). So if Peter would
not object against -- I would really like to better have BUG_ON
check there :) Peter?
http://lkml.org/lkml/2008/8/3/269
http://lists.openwall.net/linux-kernel/2008/05/14/130
- Cyrill -
prev parent reply other threads:[~2008-10-20 18:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-18 20:03 Cyrill Gorcunov
2008-10-18 20:28 ` Peter Zijlstra
2008-10-19 5:29 ` Cyrill Gorcunov
2008-10-20 18:12 ` Hiroshi Shimamoto
2008-10-20 18:20 ` Cyrill Gorcunov [this message]
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=20081020182038.GB503@localhost \
--to=gorcunov@gmail.com \
--cc=h-shimamoto@ct.jp.nec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--subject='Re: CFS related question' \
/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
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).