Date: Sat, 23 Jan 2010 15:54:21 +0000 (UTC) From: Attilio Rao <attilio@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/kern kern_mutex.c sched_4bsd.c sched_ule.c Message-ID: <201001231554.o0NFsWX4072658@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
attilio 2010-01-23 15:54:21 UTC
FreeBSD src repository
Modified files:
sys/kern kern_mutex.c sched_4bsd.c sched_ule.c
Log:
SVN rev 202889 on 2010-01-23 15:54:21Z by attilio
- 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
Revision Changes Path
1.218 +0 -2 src/sys/kern/kern_mutex.c
1.135 +5 -2 src/sys/kern/sched_4bsd.c
1.264 +6 -21 src/sys/kern/sched_ule.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001231554.o0NFsWX4072658>