mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Ingo Molnar <mingo@elte.hu>
Cc: Fabio Comolli <fabio.comolli@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [patch] sched: remove __resched_legal() and fix cond_resched_softirq()
Date: Wed, 27 Dec 2006 16:56:28 +0900	[thread overview]
Message-ID: <87ac19epqr.fsf@duaron.myhome.or.jp> (raw)
In-Reply-To: <20061226130739.GB3701@elte.hu> (Ingo Molnar's message of "Tue\, 26 Dec 2006 14\:07\:39 +0100")

Ingo Molnar <mingo@elte.hu> writes:

> * OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
>
>> "Fabio Comolli" <fabio.comolli@gmail.com> writes:
>> 
>> > Just found this in syslog. It was during normal activity, about 6
>> > minutes after resume-from-ram. I never saw this before.
>> 
>> It seems someone missed to check PREEMPT_ACTIVE in __resched_legal().
>
> but PREEMPT_ACTIVE is 0x10000000, not 0x20000000.
>
>> Could you please test the following patch?
>
> no. cond_resched() is always legal in the !PREEMPT case.
>
> i found another bug and realized that the whole __resched_legal() 
> approach is fundamentally wrong! The patch below fixes this.

Hmm.. but the path seems,

-> cond_resched()
  -> if (__resched_legal())		/* preempt_count == 0 */
    -> __cond_resched()			/* preempt_count == 0x10000000 */
      -> schedule()
        [...]
        -> cond_resched()
          -> if (__resched_legal())	/* preempt_count == 0x10000000 */
            -> __cond_resched()		/* preempt_count == 0x20000000 */
              -> schedule()             /* warning */

Where is it prevented? Or warning is just wrong?

> ------------------->
> Subject: [patch] sched: remove __resched_legal() and fix cond_resched_softirq()
> From: Ingo Molnar <mingo@elte.hu>
>
> remove the __resched_legal() check: it is conceptually broken. The 
> biggest problem it had is that it can mask buggy cond_resched() calls. A 
> cond_resched() call is only legal if we are not in an atomic context. 
> But __resched_legal() hid this fact. Same goes for cond_resched_locked() 
> and cond_resched_softirq().
>
> furthermore, the __legal_resched(0) call was buggy in 
> cond_resched_softirq() and caused unnecessary long softirq latencies!
>
> the fix is to preserve the only valid inhibitor to voluntary preemption: 
> if the system is still booting. None of the other behavior of 
> __resched_legal() made any sense.
>
> the effect of this fix should be more real bugs exposed, and shorter 
> softirq latencies.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  kernel/sched.c |   17 +++--------------
>  1 file changed, 3 insertions(+), 14 deletions(-)
>
> Index: linux/kernel/sched.c
> ===================================================================
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
>  	return 0;
>  }
>  
> -static inline int __resched_legal(int expected_preempt_count)
> -{
> -#ifdef CONFIG_PREEMPT
> -	if (unlikely(preempt_count() != expected_preempt_count))
> -		return 0;
> -#endif
> -	if (unlikely(system_state != SYSTEM_RUNNING))
> -		return 0;
> -	return 1;
> -}
> -
>  static void __cond_resched(void)
>  {
>  #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
> @@ -4647,7 +4636,7 @@ static void __cond_resched(void)
>  
>  int __sched cond_resched(void)
>  {
> -	if (need_resched() && __resched_legal(0)) {
> +	if (need_resched() && system_state == SYSTEM_RUNNING) {
>  		__cond_resched();
>  		return 1;
>  	}
> @@ -4673,7 +4662,7 @@ int cond_resched_lock(spinlock_t *lock)
>  		ret = 1;
>  		spin_lock(lock);
>  	}
> -	if (need_resched() && __resched_legal(1)) {
> +	if (need_resched() && system_state == SYSTEM_RUNNING) {
>  		spin_release(&lock->dep_map, 1, _THIS_IP_);
>  		_raw_spin_unlock(lock);
>  		preempt_enable_no_resched();
> @@ -4689,7 +4678,7 @@ int __sched cond_resched_softirq(void)
>  {
>  	BUG_ON(!in_softirq());
>  
> -	if (need_resched() && __resched_legal(0)) {
> +	if (need_resched() && system_state == SYSTEM_RUNNING) {
>  		raw_local_irq_disable();
>  		_local_bh_enable();
>  		raw_local_irq_enable();

-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2006-12-27  7:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-24 13:53 BUG: scheduling while atomic - Linux 2.6.20-rc2-ga3d89517 Fabio Comolli
2006-12-24 16:58 ` OGAWA Hirofumi
2006-12-25 19:02   ` Fabio Comolli
2006-12-26 17:15     ` Pavel Machek
2006-12-26 17:25       ` Fabio Comolli
2006-12-26 17:27       ` Randy Dunlap
2006-12-26 13:07   ` [patch] sched: remove __resched_legal() and fix cond_resched_softirq() Ingo Molnar
2006-12-27  7:56     ` OGAWA Hirofumi [this message]
2006-12-27 11:16       ` Ingo Molnar

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=87ac19epqr.fsf@duaron.myhome.or.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=akpm@osdl.org \
    --cc=fabio.comolli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.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

all inboxes | Powered by JetHome®