Bug about sched_4bsd?
Kohji Okuno
okuno.kohji at jp.panasonic.com
Wed Jan 20 02:52:33 UTC 2010
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 curthread.
>> curthread will be sched_lock and the sleeping thread will be a sleepq lock.
>> I 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. Someone should look at other maybe_resched callers 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 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"
More information about the freebsd-current
mailing list