Date: Fri, 12 Sep 2008 18:36:19 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 sys_machdep.c Message-ID: <20080912153619.GK39652@deviant.kiev.zoral.com.ua> In-Reply-To: <200809121022.36441.jhb@freebsd.org> References: <200809120951.m8C9pOZj037333@repoman.freebsd.org> <200809121022.36441.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Bina0ufSB9dLMnVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 12, 2008 at 10:22:35AM -0400, John Baldwin wrote: > On Friday 12 September 2008 05:51:11 am Konstantin Belousov wrote: > > kib 2008-09-12 09:51:11 UTC > >=20 > > FreeBSD src repository > >=20 > > Modified files: > > sys/i386/i386 sys_machdep.c=20 > > Log: > > SVN rev 182960 on 2008-09-12 09:51:11Z by kib > > =20 > > The user_ldt_alloc() function shall return with dt_lock locked. > > The user_ldt_free() function shall return with dt_lock unlocked. > > Error handling code in both functions do not handle this, fix it by > > doing necessary lock/unlock. > > =20 > > While there, fix minor style nits. >=20 > Hmm, I had actually thought it was intentional for user_ldt_alloc() to on= ly=20 > return with the lock held on success and depend on a later call to anothe= r=20 > method to drop the lock in the success case (so the locking isn't visible= to=20 > consumers of the API in theory). For example, i386_ldt_grow() depended o= n=20 > this feature and is now broken (it leaks a lock on failure). I missed th= is=20 > when looking at this yesterday. I probably miss something there. On failure of user_ldt_alloc(), i386_ldt_grow() does return (ENOMEM), without changing lock state for dt_lock. There are three call locations for the i386_ldt_grow(), all of them in i386_set_ldt(). On failure, each call location does mtx_unlock_spin(&dt_lock) immediately after call. So I assumed that protocol for i386_ldt_grow() is to always return with dt_lock locked. Two other callers of the user_ldt_alloc() in cpu_fork() do panic() immediately after the failed call to user_ldt_alloc(). Could you, please, point me to exact place where the lock would leak ? >=20 > Other notes: >=20 > - Since user_ldt_free() handles the case of there not being an LDT, the c= ode > in exec_setregs() on i386 can be simplified to just always call > user_ldt_free(). > - cpu_exit() could possibly do the same. I wonder if exec_setregs() need= s the > same fixup to %gs that cpu_exit() does. If so, that could possibly be = moved > into user_ldt_free(). Ah, exec_setregs() does it unconditionally. I t= hink > you could make cpu_exit() just do it unconditionally as well before cal= ling > user_ldt_free(). >=20 > --=20 > John Baldwin --Bina0ufSB9dLMnVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjKjHMACgkQC3+MBN1Mb4jFMwCeKwnd9Sw/+0yRnxck35kzBolg E7QAoMEQijLNzhGJBW4IlRsc0MAbfKv0 =Atvt -----END PGP SIGNATURE----- --Bina0ufSB9dLMnVr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080912153619.GK39652>