From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 17:23:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE5A416A419 for ; Mon, 13 Aug 2007 17:23:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1CE13C46E for ; Mon, 13 Aug 2007 17:23:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4462D487F4; Mon, 13 Aug 2007 19:23:39 +0200 (CEST) Received: from localhost (public-gprs36066.centertel.pl [91.94.12.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id B1A2945B26; Mon, 13 Aug 2007 19:23:25 +0200 (CEST) Date: Mon, 13 Aug 2007 19:22:25 +0200 From: Pawel Jakub Dawidek To: Max Laier Message-ID: <20070813172225.GB8819@garage.freebsd.pl> References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <200708112129.29751.max@love2party.net> <20070811205437.GA24731@garage.freebsd.pl> <200708131431.13088.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <200708131431.13088.max@love2party.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, Rong-en Fan , Kris Kennaway Subject: Re: panic: sleeping thread owns a non-sleepable lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 17:23:40 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 13, 2007 at 02:31:06PM +0200, Max Laier wrote: > > It looks like a whole lot of complex code can be run with pfil rwlock > > held. More complex code - harder to avoid sleeping. Is it not possible > > to call ->pfil_func() without holding pfil rwlock? For example by > > acquiring the lock, taking a hook, increasing its reference count so it > > won't go away, dropping the lock and calling ->pfil_func() ? >=20 > Won't help a bit. There are other locks on the way that would need=20 > similar changes. I believe that things that hook into pfil(9) must be=20 > aware that they are running in the hot transmission path. Actions that= =20 > can not be performed with a mutex held must be deferred to another=20 > context. Note that traditional pfil(9) consumers used to run at splnet,= =20 > where sleeping is a bad idea as well. After I send that e-mail, I realized that sleeping with read lock should be ok. When we acquire read lock and sleep, other readers can also acquire it and when we need write lock, we don't operate in fast path (I assume we need write lock when we register/deregister hook mostly). In other words we could change pfil lock from rwlock(9) to sx(9). In this very case posted in the begining of the thread I see nothing wrong in thread sleeping in sendfile(2), because it won't affect other processes. BUT if as you said there are other locks in the way, my idea doesn't apply. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGwJNRForvXbEpPzQRAvAbAKCV48ah9iTZg54dfe5mHJ7rGKRmUACg24u+ R1vxtog9kxSohYvGbI0dhLc= =R8LI -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O--