svn commit: r202889 - head/sys/kern
Attilio Rao
attilio at freebsd.org
Tue Jan 26 07:10:33 UTC 2010
2010/1/26 Rob Farmer <rfarmer at predatorlabs.net>:
> On Sat, Jan 23, 2010 at 7:54 AM, Attilio Rao <attilio at freebsd.org> wrote:
>> Author: attilio
>> Date: Sat Jan 23 15:54:21 2010
>> New Revision: 202889
>> URL: http://svn.freebsd.org/changeset/base/202889
>>
>> Log:
>> - Fix a race in sched_switch() of sched_4bsd.
>> In the case of the thread being on a sleepqueue or a turnstile, the
>> sched_lock was acquired (without the aid of the td_lock interface) and
>> the td_lock was dropped. This was going to break locking rules on other
>> threads willing to access to the thread (via the td_lock interface) and
>> modify his flags (allowed as long as the container lock was different
>> by the one used in sched_switch).
>> In order to prevent this situation, while sched_lock is acquired there
>> the td_lock gets blocked. [0]
>> - Merge the ULE's internal function thread_block_switch() into the global
>> thread_lock_block() and make the former semantic as the default for
>> thread_lock_block(). This means that thread_lock_block() will not
>> disable interrupts when called (and consequently thread_unlock_block()
>> will not re-enabled them when called). This should be done manually
>> when necessary.
>> Note, however, that ULE's thread_unblock_switch() is not reaped
>> because it does reflect a difference in semantic due in ULE (the
>> td_lock may not be necessarilly still blocked_lock when calling this).
>> While asymmetric, it does describe a remarkable difference in semantic
>> that is good to keep in mind.
>>
>> [0] Reported by: Kohji Okuno
>> <okuno dot kohji at jp dot panasonic dot com>
>> Tested by: Giovanni Trematerra
>> <giovanni dot trematerra at gmail dot com>
>> MFC: 2 weeks
>>
>> Modified:
>> head/sys/kern/kern_mutex.c
>> head/sys/kern/sched_4bsd.c
>> head/sys/kern/sched_ule.c
>
> Hi,
>
> This commit seems to be causing me a kernel panic on sparc64 - details
> are in PR 143215. Could you take a look before MFCing this?
I think that the bug may be in cpu_switch() where the mutex parameter
for sched_4bsd is not handled correctly.
Does sparc64 support ULE? I don't think it does and I think that it
simply ignores the third argument of cpu_switch() which is vital now
for for sched_4bsd too (what needs to happen is to take the passed
mutex and to set the TD_LOCK of old thread to be the third argument).
Unluckilly, I can't do that in sparc64 asm right now, but it should
not be too difficult to cope with it.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
More information about the svn-src-all
mailing list