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 -

      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).