From owner-freebsd-arch@FreeBSD.ORG Thu Nov 25 00:16:28 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0554B1065673; Thu, 25 Nov 2010 00:16:28 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 91B508FC0A; Thu, 25 Nov 2010 00:16:27 +0000 (UTC) Received: by qyk7 with SMTP id 7so347121qyk.13 for ; Wed, 24 Nov 2010 16:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=Omy9CdauFR4kUBVNel4sFMv+R8UWSs3Tp2sgqiNsr1c=; b=OF2mz1bF5ajBK0sosmW6Krw8N7ig7dHjc/JVzIqRekU9Ab0r9B620N1vWXpAUZ8WQV /O9vemeOZ1o7iN3K/LLNjRGhi1uuqaq5rfo/YOsTMHeEmioRcgWs9wsiuBHpFAqvcCk1 2Y48eJ4muf6AYr7fTPwc5SHaVyS48iZOMZSYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=PCI4eJWogcpUINl5i333pF38S3yUhHyTrK03SME5SYq3f0Db3FjkKmNS31mukjwq/n q1KNuRVhwBt6t4bfwElH3hcwXGIbQ1aiSAUL/XwxN96X3Z4xEcvIt7TQWi2GAW1uUTMc 3GfV4kjj4uGMoodIvy8Ol2aMV2J8lItaf2GFs= Received: by 10.224.46.91 with SMTP id i27mr58864qaf.15.1290642589109; Wed, 24 Nov 2010 15:49:49 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id t35sm48456qco.18.2010.11.24.15.49.46 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Nov 2010 15:49:47 -0800 (PST) Date: Wed, 24 Nov 2010 18:49:34 -0500 From: Alexander Kabaev To: mdf@FreeBSD.org Message-ID: <20101124184934.35b6766a@kan.dnsalias.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/oZMNvJGH7Ed6yHC8LkuAeoU"; protocol="application/pgp-signature" Cc: freebsd-arch@freebsd.org Subject: Re: LOR with sysctl lock X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 00:16:28 -0000 --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--