From owner-freebsd-arch@FreeBSD.ORG Wed Nov 24 19:53:59 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 DDDF91065670 for ; Wed, 24 Nov 2010 19:53:59 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A88B28FC17 for ; Wed, 24 Nov 2010 19:53:59 +0000 (UTC) Received: by iwn39 with SMTP id 39so125815iwn.13 for ; Wed, 24 Nov 2010 11:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=1KagsOHxQZmohCZJ7c58koL99oXuUFKHJn4/yxAzAWQ=; b=crsxnRByGUQsGOLLqjfFWwidVpIQoYXXQM9IR27LhwrS7RAhYhepqNx9Hgflz0UsQz JktLHlEf65pKyj1E1JoO7UcDvXVBF9KBbRP5YOyPf0if+VDYUrCnSu7BduUgwyNpbS7Q FC1hUzQ+zBcXO65YL6jAYJ8WWQYgsYf6psj1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=LW+TVAgwSHFhJlg2uW3qRbXSMTC05p0eN/sx10fwJGXygQZhziuFiIkkZziPmBf/bM lt5PWvgS8oI+n66QNGErCYyY0gFz0Nr9148iI4kWAD5eW1XWy/jKYSMbZir1cZQisL28 2FLRwKhlHDqdzCAsW3JgRsFEdgF1UxcukVfgc= MIME-Version: 1.0 Received: by 10.231.156.139 with SMTP id x11mr9995848ibw.22.1290628438459; Wed, 24 Nov 2010 11:53:58 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Wed, 24 Nov 2010 11:53:58 -0800 (PST) Date: Wed, 24 Nov 2010 11:53:58 -0800 X-Google-Sender-Auth: ICLmQ74lfFiJ30Er5tiJRtncOU0 Message-ID: From: mdf@FreeBSD.org To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: 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: Wed, 24 Nov 2010 19:53:59 -0000 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. 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. 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. Patch: http://people.freebsd.org/~mdf/0001-Proposed-patch-to-fix-LORs-with-sysctl-lock.patch If there are no objections, I'd like to commit this next week. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Wed Nov 24 21:20:44 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 849801065672; Wed, 24 Nov 2010 21:20:44 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 15B428FC0A; Wed, 24 Nov 2010 21:20:43 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oAOLKdf9096710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 22:20:39 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1290633639; bh=dM/UKjvnwDU30mnnmQo9m0TKsHzllPHJEnz4w5iRtXM=; h=Date:From:To:Cc:Subject:Message-ID:Reply-To:References: MIME-Version:Content-Type:In-Reply-To; b=q46rUxWezYoUX0gz9MRcOR+SsIslRZe3nnJykohdlQfEk3yA3HhwUX3Z+L2W3jyy7 XuKEhvyLWQKiJqaSHPeXWfACbeLzPagCSRmyGUsb7TNJO0EkW4k5ufhfSnxKB6r6Tk A8qcrZJNT5O8sHR2z4N0psJR9JlB2D6ovcQL7Doo= Date: Wed, 24 Nov 2010 22:20:39 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Peter Jeremy Message-ID: <20101124212039.GL3120@acme.spoerlein.net> Mail-Followup-To: Peter Jeremy , freebsd-arch@freebsd.org, stable@FreeBSD.org References: <20101118222100.GA47116@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101118222100.GA47116@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org, freebsd-arch@freebsd.org Subject: Are there digi(4) users running -STABLE? (was Re: Migrating ISA/PCI drivers) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stable@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 21:20:44 -0000 [cross-posting to stable@, where some of those folk might hang out] On Fri, 19.11.2010 at 09:21:00 +1100, Peter Jeremy wrote: > I'm (belatedly) looking at porting digi(4) to the MPSAFE TTY system > and have some architectural questions. > > The digi(4) driver appears to support 5 different Digi card variants, > at least two of which exist in both ISA and PCI variants. Looking at > the Digi website, it appears that both PCI and ISA cards are still > available (as well as a PCIe card which is unlikely to work with the > current driver). I only have access to PCI/Xem cards and so can't > test my changes on any other card types. I presume Digi cards are not > that popular because noone else has shown any interest in the driver > since the MPSAFE TTY changes were announced about 2.5 years ago. > > How much effort should I invest in adapting code for other card types? > In particular, the ISA cards use windowed memory accesses and IO ports > where the PCI cards have a single flat memory aperture. Removing > support for ISA cards would simplify the code (and remove the need to > make decisions about whether I need to do window switches in new > code), as well as potentially allowing finer grained locks. > > My options would seem to be: > 1) Rip out the ISA support - this is the cleanest for me but maximises > effort for a future person wanting to support ISA Digi cards. > 2) Carry forward the ISA code as best I can and ensure new code includes > appropriate window switches etc. This maximises my effort but > hopefully makes it easier for someone to get ISA cards working. > 3) Ignore the ISA code. This is fairly easy but probably requires > similar effort to (1) to get it going on ISA since all the code > would need to be reviewed to add necessary ISA-specific locking/ > window switching. > > My preference is 1 since it leaves the least cruft (from my point of > view) in the code and doesn't give users the false impression that > ISA cards work. > > I would appreciate some advice on the best way forward. In the > absence of any input, I will probably stick with option 3 for now but > may move to option 1 if the ISA code starts getting in the way. Keep > in mind that digi(4) does not currently compile on FreeBSD-8 or later, > so any of the above options are an improvement over the status quo, > though all are a regression from FreeBSD-7. > > Of course, if someone has access to other Digi card types and wants > to assist with porting and testing, I would be happy to work with them. > > -- > Peter Jeremy 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-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 25 01:23:05 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 7FD07106566C for ; Thu, 25 Nov 2010 01:23:05 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 43A998FC16 for ; Thu, 25 Nov 2010 01:23:04 +0000 (UTC) Received: by iwn39 with SMTP id 39so436064iwn.13 for ; Wed, 24 Nov 2010 17:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=OdXdCikEaabJPzC+cJO3+NSluQ24Xq/5iep+xKRd09E=; b=T4hJzwWgYhopvNXjMkXhwIkHsKEyFxS9fU1rLMXbsT5Kcaal0z5DZxRrwPJzdhfD0Z cHL4Q1MCzRUirP+jvitGJ7ECQfclPGM7OjN6r6hA83LpWJQCGMzhCXh5em0TnryIstKd atzLU2veHwkvbxFRiXTCrq/i7HomxoDkikbSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CBal6IE+T0VH4sIbzMTQoHlPRODu5ASkbqSeR654cPvJCcXFLOM+RZZRP6X4vH7Mc+ A/1xR+UNY5hlsTt5hrjWOrzeVg864Rkxeoia/oZxXYonxzm6YSDyBa0Y0rSK+Vr9c7sP cSpDgGCNdVN2aZ9JU/nPk1Uxqqv/jJqkrBBhs= MIME-Version: 1.0 Received: by 10.231.35.203 with SMTP id q11mr54853ibd.197.1290648184281; Wed, 24 Nov 2010 17:23:04 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Wed, 24 Nov 2010 17:23:04 -0800 (PST) In-Reply-To: <20101124184934.35b6766a@kan.dnsalias.net> References: <20101124184934.35b6766a@kan.dnsalias.net> Date: Wed, 24 Nov 2010 17:23:04 -0800 X-Google-Sender-Auth: pr-Aq6q0njrAkPeRC2ezXNRxlyw Message-ID: From: mdf@FreeBSD.org To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 01:23:05 -0000 On Wed, Nov 24, 2010 at 3:49 PM, Alexander Kabaev wrote: > On Wed, 24 Nov 2010 11:53:58 -0800 > mdf@FreeBSD.org wrote: > >> The sysctl lock can cause "random" LOR warnings. =A0These 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. =A0The >> 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. >> >> The below patch will fix the problem generically and with no changes >> to other code. =A0I 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. >> >> 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. =A0The only exception is canbus_detach() >> in pc98/pc98/canbus.c. =A0So I wonder if sysctl_ctx_free(9) should >> return void and print a warning itself. >> >> Patch: >> http://people.freebsd.org/~mdf/0001-Proposed-patch-to-fix-LORs-with-sysc= tl-lock.patch >> >> If there are no objections, I'd like to commit this next week. >> >> 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? D'oh, yeah. I'm thinking of something a little more grand, now, that increments a hold count on the sysctl oid and releases the lock before calling the handler. This would prevent the LOR, and allow sysctl_ctx_free(9) to be run in-line, but it would then have to wait for any in progress sysctl calls to an oid to drain. I think this will work out; I'm planning to work on the code over the Thanksgiving holiday and have something ready in a few days. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Nov 25 02:36:46 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 A82F01065694; Thu, 25 Nov 2010 02:36:46 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3973C8FC0C; Thu, 25 Nov 2010 02:36:45 +0000 (UTC) Received: by qwb8 with SMTP id 8so442062qwb.13 for ; Wed, 24 Nov 2010 18:36:45 -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=ktgSnwTTnfqILV4flf6rVAL3cxy6ZL1etkBt4lfJdFw=; b=tl7KjVRwPEbu9FFsDwX1Ash9cfiMsYk16lg+57lYy3mAKjJiBnjZ2U3Ixbg6fTMpPD 3Yl1j04v4gIWoV1RL9iaT+0zY1nqTkee/0FssuqfUvQWKWjS4RULb+Xb10s6ZUWtv+CA Q+nqJtH4zDH89kGabQ/w8MH1gz7+RK43y4GAk= 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=X7PY3UPdfM3O8aHNSCCpft+r505PbrBamvWDq00XGJM9XZPucm1uuLZm0meiD/SyKH aV3/S2+afvCANXN8hd4RMgGUiS52UMhUmN4CJBHfeNTULSXH1NOw53SfaRtBEUj56vgn JojjB2IWBHGM33sm1ShVHEKrKyYAhuYDa1Yp4= Received: by 10.229.222.194 with SMTP id ih2mr141144qcb.140.1290652605310; Wed, 24 Nov 2010 18:36:45 -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 t17sm151424qcp.38.2010.11.24.18.36.44 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Nov 2010 18:36:44 -0800 (PST) Date: Wed, 24 Nov 2010 21:36:27 -0500 From: Alexander Kabaev To: mdf@FreeBSD.org Message-ID: <20101124213627.2d95840f@kan.dnsalias.net> In-Reply-To: References: <20101124184934.35b6766a@kan.dnsalias.net> 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_/vvhl+h.8WdHpfPo9wmi7wz0"; 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 02:36:46 -0000 --Sig_/vvhl+h.8WdHpfPo9wmi7wz0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Wed, 24 Nov 2010 17:23:04 -0800 mdf@FreeBSD.org wrote: > On Wed, Nov 24, 2010 at 3:49 PM, Alexander Kabaev > wrote: > > On Wed, 24 Nov 2010 11:53:58 -0800 > > mdf@FreeBSD.org wrote: > > > >> The sysctl lock can cause "random" LOR warnings. =9AThese 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. =9AThe 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. > >> > >> The below patch will fix the problem generically and with no > >> changes to other code. =9AI 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. > >> > >> 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. =9AThe only exception is > >> canbus_detach() in pc98/pc98/canbus.c. =9ASo I wonder if > >> sysctl_ctx_free(9) should return void and print a warning itself. > >> > >> Patch: > >> http://people.freebsd.org/~mdf/0001-Proposed-patch-to-fix-LORs-with-sy= sctl-lock.patch > >> > >> If there are no objections, I'd like to commit this next week. > >> > >> 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 > D'oh, yeah. >=20 > I'm thinking of something a little more grand, now, that increments a > hold count on the sysctl oid and releases the lock before calling the > handler. This would prevent the LOR, and allow sysctl_ctx_free(9) to > be run in-line, but it would then have to wait for any in progress > sysctl calls to an oid to drain. >=20 > I think this will work out; I'm planning to work on the code over the > Thanksgiving holiday and have something ready in a few days. >=20 > Thanks, > matthew This sounds like a useful strategy, but I think you are attacking wrong problem here. The linker running initialization code code under lock is problematic and something like mutex to protect linker module lists and some kind of gate with global flag allowing only one thread into module load/unload code path should address the same annoying LOR as well and possibly many more. Having sysctl handlers running outside of sysctl lock is still a very worthwhile goal IMHO. --=20 Alexander Kabaev --Sig_/vvhl+h.8WdHpfPo9wmi7wz0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFM7cu7Q6z1jMm+XZYRAgnAAKCuWEnBWpjGsVJudCxgALnWnz/8zgCfcUHZ hccRwnOS/3g0PFurSdJbHe4= =oH2w -----END PGP SIGNATURE----- --Sig_/vvhl+h.8WdHpfPo9wmi7wz0-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 25 12:59:23 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 EF0BE1065675 for ; Thu, 25 Nov 2010 12:59:23 +0000 (UTC) (envelope-from advertdb@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB3E8FC1F for ; Thu, 25 Nov 2010 12:59:23 +0000 (UTC) Received: by mail-fx0-f54.google.com with SMTP id 19so789529fxm.13 for ; Thu, 25 Nov 2010 04:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:from:reply-to:to :subject:content-type:content-transfer-encoding:x-mailer:date :message-id; bh=Leb7O5rc1NezaOmiOudULj5Djj0rMh8wK8DRZnVXWqQ=; b=vWRZUi6PqvgvOuW5ndFt3kFuywLeUN5ytmsJZER82mRwe8/3qXDNQ3UG07m1fur0nn U7OV63/uoWC1o2zdFmC+i7yFqF/u0pyBJrEv92z271yrYNB7a+aA/xFsJlwfOa7+nRbc usK2cCxEqpJHACUS6u7rv+azSdGwyErQCZbAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:reply-to:to:subject:content-type :content-transfer-encoding:x-mailer:date:message-id; b=ubqn9hFrw0evhH4KzyfY3vOZPXMSgx8K4DBmxYR+F4n5mgOkWWG5cgXFOqilhAtDIo 5esubXWwkqaaLcGLjpOvoIOLRj+4qdoOJ15OVDheOp0TpaNNVOHQP8rXF1/XWqSSxAI6 dTKxo6sIHnRHe1itT3UArX3DVN4s9YVf0gbAU= Received: by 10.223.96.198 with SMTP id i6mr695093fan.10.1290688402056; Thu, 25 Nov 2010 04:33:22 -0800 (PST) Received: from tigereyes (196-215-27-149.dynamic.isadsl.co.za [196.215.27.149]) by mx.google.com with ESMTPS id 21sm173754fav.17.2010.11.25.04.33.19 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Nov 2010 04:33:21 -0800 (PST) From: "Laurinda Wernars Database Development" To: freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable X-Mailer: SendBlaster.1.5.5 Date: Thu, 25 Nov 2010 14:33:20 +0200 Message-ID: <3188636463041279118870@tigereyes> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Database Development for just R5900! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: advertdb@gmail.com 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 12:59:24 -0000 = La= urinda Wernars PERSONALISED DATABASE DESIGN &nbs= p;Get y= our company=92s information organised Existi= ng Databases or Developed to your specifications at a price you can afford.= Written in MS Access 2000, the following have been developed and are being= used extensively by the companies they were written for. The databas= es have assisted the companies in streamlining the workload and managing th= e workflow. = Examples: Sales / Customer Relation= ship Management Keep= Track of deals the sales staff are working on, when follow up needs to hap= pen, appointments with Customers that are due. What product / service= is most sought after, and how successful are they on each deal. Fault Tracking & Repo= rting Any = and all equipment brought in for repairs, who the technician was, what comp= onents were at fault, what still hasn=92t been handled. Reports on any of t= he above criteria and more. Employment / Recruiting Keep= track of candidates interested in new careers, search and sort by criteria= such as AA, Area, Qualifications, Industries worked in. Also keep tr= ack of Jobs to be filled for Clients, specifications, interviews setup, fol= low up needed etc. Training A co= mplete solution for small to medium sized training companies. From tr= ainers to learners, to equipment required, to venue, to marketing drives an= d last but not least automatic certificate printing by simply entering the = date it will complete the learner information, course attended and even put= in electronic signatures of the trainer and Owner / Director of the compan= y! This is a must have for any company dealing with the Seta=92s Quotations Ideal for Products based companies that want to speed up = their quotations process and to keep track of any actions around the quotes= , put in follow up dates and what needs to be done as well as link any othe= r supporting documentation so as to keep everything in one place. Auditing / = Tax Consultants A co= mplete client listing as required by the Seta. Tracking of Submission of In= formation to Receiver, Annual Returns, Information Act data etc. Keep= everything in one place at your finger tips! Medical =96 = Workman=92s Compensation Claims Capture and Print all the information required for Workman=92s Com= pensation Claims in a Medical Practice, tracking the Incident from date of = opening until payment is complete. Enter info once only for Employers= , Physiotherapists, Radiologists etc and use for all future claims. P= rint the WCL4 AND WCL 5 Claim forms from the directly from database.= Insurance Lo= ss Adjusters New!! Have claim n= umbers, case numbers etc available at the click of a button, as well as lin= k all the documents associated to the claim for ease of use later. Keep track of Invoices and Payments = made with appropriate reports. Month End Reports availab= le on all of the above! = ALSO ON OFFER: I ha= ve an extensive database of company names and email addressed in various in= dustries throughout South Africa! (Over 1 million!) If you are lo= oking at extending your marketing contact me for a quote on what I have. lwdatabasedev@gmail.com P.O.Box 121 Honeydew2040 [1]http://lwdatabasedev.w= ebs.com If you no longer wish to receive e= mail from me please reply to this message and change the title to Unsubs= cribe and it will be done immediately. References 1. 3D"http://lwdatabasedev.webs.com"/ From owner-freebsd-arch@FreeBSD.ORG Thu Nov 25 15:48:57 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28381065673 for ; Thu, 25 Nov 2010 15:48:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 200348FC19 for ; Thu, 25 Nov 2010 15:48:56 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAPFmqjZ018931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Nov 2010 17:48:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAPFmqR5025471; Thu, 25 Nov 2010 17:48:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAPFmqOi025470; Thu, 25 Nov 2010 17:48:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Nov 2010 17:48:52 +0200 From: Kostik Belousov To: arch@freebsd.org, amd64@freebsd.org Message-ID: <20101125154852.GR2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IltA/rM2wonYuhj8" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: Non-executable stacks 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 15:48:57 -0000 --IltA/rM2wonYuhj8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, at the http://people.freebsd.org/~kib/misc/nxstacks.1.patch please find the patch that implements non-executable stack support for amd64 (and FreeBSD/ia32 processes executed on amd64 host). The implementation is done to take advantage of GNU toolchain PT_GNU_STACK markers. The description of them I was able to find, except the binutils and gcc source code, is at http://www.redhat.com/archives/fedora-devel-list/2003-November/msg00838.html http://www.gentoo.org/proj/en/hardened/gnu-stack.xml Notes about the patch. It consists of the following pieces that are relatively independed from each other: - Added .note.GNU-stack section for all assembly sources for i386 and amd64, used to build rtld, libc, libm and libthr. The libraries do not need executable stack, so shall be marked as such. This is the biggest and most trivial part of the patch. I had to modify contributed source for compiler-rt library. - Changed gcc configuration to emit .note.GNU-stack as appropriate, for i386 and amd64. - Moved signal trampolines off the main process stack. For this, I had to implement the global shared page n-th time. Simple allocator is provided to carve properly aligned chunks of the page space. Used by image activators to allocate space for the trampolines. - ELF activator parses PT_GNU_STACK phdr and sets the stack protection as specified in the image. If the phdr is missing, rwx is used, as before. - rtld is supplied with the main stack protection mode a by new aux vector. If any dso is loaded that requires executable stack and current protection disables execution from stack, __pthread_map_stacks_exec() is called. - For single-threaded process, libc provides the weak implementation of __pthread_map_stacks_exec that calls mprotect() on the main process stack. - For multi-threaded process, libthr provides __pthread_map_stacks_exec() that changes protection of all allocated stacks. New rtld interface _rtld_get_stack_prot() is used to properly set protection for created threads. It is curious enough that HEAD allocates the main stack on amd64 as executable, but libthr marks all stacks for non-initial thread as not executable ! This should already break some gcc features when used from non-initial thread. --IltA/rM2wonYuhj8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzuhWQACgkQC3+MBN1Mb4gougCgyFDpcpeBGccPLew59uVgmJUA S+oAniEHKhH3MdzbIHI62wt0yOrP4QIp =xe92 -----END PGP SIGNATURE----- --IltA/rM2wonYuhj8-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 26 01:44:08 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 AFCF6106564A for ; Fri, 26 Nov 2010 01:44:08 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 795CC8FC17 for ; Fri, 26 Nov 2010 01:44:08 +0000 (UTC) Received: by iwn39 with SMTP id 39so1750374iwn.13 for ; Thu, 25 Nov 2010 17:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ovd3qwdqgx4o8HpAXVncPT1cNT8zcktJnjlCvRg4aME=; b=T6cm4quHDanp8hfQzpMM9DJAw8ivBEt5VhIZKDIs7MchNSgFGXNfnUORQUW8bqWmNb /61/zMoc7P7vlKxWPiv4bwa+HJECYSv9NipiV5xL/SOoVeyTyCCgpH23isR7h92qpyBr H3Xe3ctIp3wsfKohq3BNY2OY++6vYppMBNQYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=XyC3LAD0MYNnSHUYgTcSkswRQ6FJc/DlrUcSR80WvEB7+dXAdUoXT2Evrepz+7mj8I Pve+xM17dqcptCL1/rc6GjKVMv4iVpVfD0eYiiN/XHB9teSB9X2MC58tn4ZUQhstPU68 BbEtNPShvxaElPRqeWTCn98SWtj15NocvwtmA= MIME-Version: 1.0 Received: by 10.231.10.69 with SMTP id o5mr888877ibo.122.1290735847806; Thu, 25 Nov 2010 17:44:07 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Thu, 25 Nov 2010 17:44:07 -0800 (PST) Date: Thu, 25 Nov 2010 17:44:07 -0800 X-Google-Sender-Auth: X4sZmQVK3i8r6VtSDEwk6LzO4qc Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch Content-Type: text/plain; charset=ISO-8859-1 Subject: Fixing sysctl LOR 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: Fri, 26 Nov 2010 01:44:08 -0000 My previous thought on the matter was incorrect. This patch (and two small cleanups before it) mean the sysctl lock is no longer held across the call to oid_handler, which means that WITNESS will no longer make entries where sysctl lock is taken before any random lock in the handler. The idea is simple; keep track of the number of threads running the handler so that the oid is not deleted (and sysctl_ctx_free(9) doesn't return) before all threads are drained. It does unfortunately mean that the sysctl lock is only taken in exclusive mode, but since it's held for less time I don't anticipate a significant loss of concurrency. If there is a simple benchmark someone can recommend I'd be happy to check the difference. I would like at some point to also reduce the number of calls to sysctl(2) made by sysctl(8); this would also help performance. Among other things I wonder if eliminating the numerical array to describe an oid would be acceptable; in a few circumstances it would mean longer comparisons (strcmp versus integer comparison) but for many uses it eliminates the name2oid step, and it would also mean there's no longer a need for fixed numbered entries. Cleanup: http://people.freebsd.org/~mdf/0001-Use-the-SYSCTL_CHILDREN-macro-in-kern_sysctl.c-to-he.patch http://people.freebsd.org/~mdf/0002-Slightly-modify-the-logic-in-sysctl_find_oid-to-redu.patch The patch: http://people.freebsd.org/~mdf/0003-Do-not-hold-the-sysctl-lock-across-a-call-to-the-han.patch Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Fri Nov 26 05:56: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 0C62310656C0 for ; Fri, 26 Nov 2010 05:56:28 +0000 (UTC) (envelope-from joe.joeoptions@gmail.com) Received: from 123843-www1.gri5th.com (123843-www1.gri5th.com [74.205.126.210]) by mx1.freebsd.org (Postfix) with ESMTP id B2E818FC3B for ; Fri, 26 Nov 2010 05:56:27 +0000 (UTC) Received: (qmail 8772 invoked by uid 48); 25 Nov 2010 22:22:29 -0600 To: freebsd-arch@freebsd.org User-Agent: ExpressionEngine 1.6.8 Date: Thu, 25 Nov 2010 22:22:29 -0600 From: "Joe" X-Sender: joe.joeoptions@gmail.com X-Mailer: ExpressionEngine 1.6.8 X-Priority: 3 (Normal) Message-ID: <4cef36058c28d@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Your Rental Property Listing X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "joe.joeoptions@gmail.com" List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 05:56:28 -0000 Hi! I believe there is a faster and easier way to rent, trade, buy and sell destination real estate and thought you might be interested in my new rental website called JoeOptions: http://www.joeoptions.com/. Here's how JoeOptions benefits you: * FREE listings through December 31, 2011 for properties created on JoeOptions. * UNLIMITED pictures/videos/links to help promote and better represent your Property and the Destination. * HomeAway Connect integration eliminating the need to manage multiple calendars * Unique property management tool allowing Renters to find your property based on Date, Price and Location in one step. * Meet People Where They Are: Social Media integration with Facebook, Twitter, YouTube, etc. Check out this video that explains why JoeOptions: http://www.youtube.com/watch?v=kohBjcuPMhE We look forward to you joining us at JoeOptions! Best Regards, Joe We've sent you this email because we think you'll enjoy using JoeOptions. If you'd rather not receive any more emails from us, please email unsubscribe@joeoptions.com, and we'll take you off our list. To remove your email from the "20101125" mailing list, click here: http://cs.joeoptions.com/index.php?ACT=5&id=BgTS92cr3s