Re: Bug about sched_4bsd?

Hello,

Thank you, Attilio.
I checked your patch. I think that your patch is better.
I tested the patch quickly, and I think it's OK.
# This probrem does not occur easily :-<


What do you think about maybe_resched()?
I have never experienced about maybe_resched(), but I think that the
race condition may occur.

<<Back Trace>>
sched_4bsd.c:	  maybe_resched()
sched_4bsd.c:	  resetpriority_thread()
sched_4bsd.c:	  sched_nice()			get thread_lock(td)
kern_resource.c:  donice()
kern_resource.c:  setpriority()			get PROC_LOCK()

static void
maybe_resched(struct thread *td)
{
        THREAD_LOCK_ASSERT(td, MA_OWNED);
        if (td->td_priority < curthread->td_priority)
                curthread->td_flags |= TDF_NEEDRESCHED;
}

I think, when td->td_lock is not &sched_lock, curthread->td_lock is
not locked in maybe_resched().

Best regards,
 Kohji Okuno.

From: Attilio Rao <attilio_at_freebsd.org>
Subject: Re: Bug about sched_4bsd?
Date: Mon, 18 Jan 2010 03:58:41 +0100
Message-ID: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50_at_mail.gmail.com>

> 2010/1/17 Kohji Okuno <okuno.kohji_at_jp.panasonic.com>:
>> Hello,
>>
>> Could you check sched_4bsd.patch, please?
> 
> I think, instead, that what needs to happen is to have sched_switch()
> to do a lock handover from sleepq/turnstile spinlock to schedlock.
> That way, if threads are willing to contest on td_lock they will be
> still inhibited.
> I'm not sure if this patch breaks any invariant, if you may test I
> would appreciate:
> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff
> 
> Reviews and comments are appreciated.
> BTW, nice catch.
> 
> Attilio
> 
> 
> -- 
> Peace can only be achieved by understanding - A. Einstein
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"