Date: Wed, 20 Jan 2010 11:52:18 +0900 (JST) From: Kohji Okuno <okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org Cc: okuno.kohji@jp.panasonic.com, freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? Message-ID: <20100120.115218.999284356098982813.okuno.kohji@jp.panasonic.com> In-Reply-To: <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> References: <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> <alpine.BSF.2.00.1001181544130.1027@desktop> <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Attilio >>> I think setpriority() can set priority to sleeping threads. >>> Is it really safe? >> >> I agree, in this code path maybe_resched is not properly locking cur= thread. >> =A0curthread will be sched_lock and the sleeping thread will be a sl= eepq lock. >> =A0I believe that since &sched_lock is ordered after container locks= it would >> be sufficient to compare the two td_lock pointers and acquire sched_= lock if >> they are not equal. =A0Someone should look at other maybe_resched ca= llers or >> add an assert that curthread->td_lock is always &sched_lock in this >> function. > = > I'm not sure I understand you well here, but I generally don't agree,= > if we speak about the current code plus the patch I posted. I understood. If the current code plus your patch, meybe_resched() is no problem. I think, your patch is perfect if theare is no problem even if a sleeping thread sets &sched_lock to td->td_lock. Why do we call thread_lock_set() in sleepq_switch() and turnstile_wait(= )? = In case of sched_4bsd, is not thread_lock_set() needed? Thank you, Kohji Okuno. > Without the patch, there is a general problem of maybe_preempt() > because sched_switch() will handle TDF_NEEDRESCHED just in racy ways > (not ensuring atomicity of td_lock operations for sleeping threads). > That's, however, still not specific to maybe_preempt() only. However:= > * If you make a problem about the callers of maybe_resched() I agree.= > The callers should assert for sched_lock to be in place. But that is > not a general problem of maybe_resched(), it is on the callers > ballpark > * If you make a problem about the locking itself, the patch IMHO > should fix it or there is still something I can't see. > = > Thanks, > Attilio > = > = > -- = > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100120.115218.999284356098982813.okuno.kohji>