Date: Wed, 20 May 2015 12:00:46 -0400 From: Alexander Kabaev <kabaev@gmail.com> To: John Baldwin <jhb@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r282971 - in head/sys: kern sys Message-ID: <20150520120046.268dde86@kan> In-Reply-To: <201505151350.t4FDocQT054144@svn.freebsd.org> References: <201505151350.t4FDocQT054144@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/alw=CGttxZ_+MlnkAqn6sCP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 15 May 2015 13:50:38 +0000 (UTC) John Baldwin <jhb@FreeBSD.org> wrote: > Author: jhb > Date: Fri May 15 13:50:37 2015 > New Revision: 282971 > URL: https://svnweb.freebsd.org/changeset/base/282971 >=20 > Log: > Previously, cv_waiters was only updated by cv_signal or cv_wait. If > a thread awakened due to a time out, then cv_waiters was not > decremented. If INT_MAX threads timed out on a cv without an > intervening cv_broadcast, then cv_waiters could overflow. To fix > this, have each sleeping thread decrement cv_waiters when it resumes. > =20 > Note that previously cv_waiters was protected by the sleepq chain > lock. However, that lock is not held when threads resume from sleep. > In addition, the interlock is also not always reacquired after > resuming (cv_wait_unlock), nor is it always held by callers of > cv_signal() or cv_broadcast(). Instead, use atomic ops to update > cv_waiters. Since the sleepq chain lock is still held on every > increment, it should still be safe to compare cv_waiters against zero > while holding the lock in the wakeup routines as the only way the > race should be lost would result in extra calls to sleepq_signal() or > sleepq_broadcast().=20 > Differential Revision: https://reviews.freebsd.org/D2427 > Reviewed by: benno > Reported by: benno (wrap of cv_waiters in the field) > MFC after: 2 weeks >=20 > Modified: > head/sys/kern/kern_condvar.c > head/sys/sys/condvar.h >=20 This breaks ZFS range locking code, which expects to be able to wakeup everyone on the condition variable and then free the structure that contains it. Having woken up threads modify cv_waiters results in a race that leads to already freed memory to be accessed. It is debatable just how correct ZFS code in its expectations, but I think this commit should probably be reverted until either ZFS is changed not to expect cv modifiable by waking threads or until alternative solution is found to the cv_waiters overflow issue fixed by this commit. --=20 Alexander Kabaev --Sig_/alw=CGttxZ_+MlnkAqn6sCP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVcr68ACgkQQ6z1jMm+XZYUBQCgoDBcawgQ7bMmkMGelCj7UfDm y4QAniQ2Vyyzzhc5s+8uwWeAYyZrDwdm =92dI -----END PGP SIGNATURE----- --Sig_/alw=CGttxZ_+MlnkAqn6sCP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150520120046.268dde86>