Date: Wed, 24 Nov 2010 18:49:34 -0500 From: Alexander Kabaev <kabaev@gmail.com> To: mdf@FreeBSD.org Cc: freebsd-arch@freebsd.org Subject: Re: LOR with sysctl lock Message-ID: <20101124184934.35b6766a@kan.dnsalias.net> In-Reply-To: <AANLkTinU78oZrw3UEKRQ3dCPFigch9CuSdsxt0=dGSBQ@mail.gmail.com> References: <AANLkTinU78oZrw3UEKRQ3dCPFigch9CuSdsxt0=dGSBQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/oZMNvJGH7Ed6yHC8LkuAeoU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 24 Nov 2010 11:53:58 -0800 mdf@FreeBSD.org wrote: > The sysctl lock can cause "random" LOR warnings. These usually show > on reboot/shutdown when sysctl_ctx_free() is called by a kernel > module, since the mod handler is called with the module lock. The > reason for the LOR is that, at least theoretically, the sysctl lock is > the first lock in any hierarchy, because a SYSCTL_PROC handler can > take any locks it wants, and will be called with the sysctl lock held > shared. >=20 > The below patch will fix the problem generically and with no changes > to other code. I slightly prefer this to an explicit > sysctl_ctx_free_sched(9), because many times code doesn't know if some > caller holds *any* lock at all; this is especially true for mod > handlers who shouldn't be expected to know how FreeBSD locks calls to > the handler. >=20 > I also note that the return value from sysctl_ctx_free(9) is almost > never checked on CURRENT, and the only places it is, the value is > merely used to print a warning. The only exception is canbus_detach() > in pc98/pc98/canbus.c. So I wonder if sysctl_ctx_free(9) should > return void and print a warning itself. >=20 > Patch: > http://people.freebsd.org/~mdf/0001-Proposed-patch-to-fix-LORs-with-sysct= l-lock.patch >=20 > If there are no objections, I'd like to commit this next week. >=20 > Thanks, > matthew Correct me if I am wrong, but doesn't this open a race where, say, device detach routine destroys the device softc and schedules sysctl context to be destroyed asynchronously via task queue? Since sysctl entries are still visible in between the point where softc is destroyed and the point where task queue picks the sysctl destroy task up, can any access to said sysctls potentially operate on now freed softc data? --=20 Alexander Kabaev --Sig_/oZMNvJGH7Ed6yHC8LkuAeoU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFM7aSZQ6z1jMm+XZYRAlo9AJ9N3VKlcDb4jji4ax48Q6F1Wvc8SgCeIhzO xZmoGCMPbLlV/GQ60AesLzM= =nsyF -----END PGP SIGNATURE----- --Sig_/oZMNvJGH7Ed6yHC8LkuAeoU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101124184934.35b6766a>