Date: Mon, 25 Jan 2010 22:25:20 -0800 From: Rob Farmer <rfarmer@predatorlabs.net> To: Attilio Rao <attilio@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r202889 - head/sys/kern Message-ID: <b025ceb71001252225r56d4b0c8qe4c6affe338e6f9f@mail.gmail.com> In-Reply-To: <201001231554.o0NFsMbx049837@svn.freebsd.org> References: <201001231554.o0NFsMbx049837@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 23, 2010 at 7:54 AM, Attilio Rao <attilio@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: > =A0- Fix a race in sched_switch() of sched_4bsd. > =A0 =A0In the case of the thread being on a sleepqueue or a turnstile, th= e > =A0 =A0sched_lock was acquired (without the aid of the td_lock interface)= and > =A0 =A0the td_lock was dropped. This was going to break locking rules on = other > =A0 =A0threads willing to access to the thread (via the td_lock interface= ) and > =A0 =A0modify his flags (allowed as long as the container lock was differ= ent > =A0 =A0by the one used in sched_switch). > =A0 =A0In order to prevent this situation, while sched_lock is acquired t= here > =A0 =A0the td_lock gets blocked. [0] > =A0- Merge the ULE's internal function thread_block_switch() into the glo= bal > =A0 =A0thread_lock_block() and make the former semantic as the default fo= r > =A0 =A0thread_lock_block(). This means that thread_lock_block() will not > =A0 =A0disable interrupts when called (and consequently thread_unlock_blo= ck() > =A0 =A0will not re-enabled them when called). This should be done manuall= y > =A0 =A0when necessary. > =A0 =A0Note, however, that ULE's thread_unblock_switch() is not reaped > =A0 =A0because it does reflect a difference in semantic due in ULE (the > =A0 =A0td_lock may not be necessarilly still blocked_lock when calling th= is). > =A0 =A0While asymmetric, it does describe a remarkable difference in sema= ntic > =A0 =A0that is good to keep in mind. > > =A0[0] Reported by: =A0 =A0 =A0Kohji Okuno > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<okuno dot kohji at jp dot= panasonic dot com> > =A0Tested by: =A0 =A0 =A0 =A0 =A0 =A0Giovanni Trematerra > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<giovanni dot trematerra a= t gmail dot com> > =A0MFC: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 weeks > > Modified: > =A0head/sys/kern/kern_mutex.c > =A0head/sys/kern/sched_4bsd.c > =A0head/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? Thanks, --=20 Rob Farmer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b025ceb71001252225r56d4b0c8qe4c6affe338e6f9f>