Date: Mon, 13 Aug 2007 19:22:25 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: freebsd-current@freebsd.org, Rong-en Fan <grafan@gmail.com>, Kris Kennaway <kris@obsecurity.org> Subject: Re: panic: sleeping thread owns a non-sleepable lock Message-ID: <20070813172225.GB8819@garage.freebsd.pl> In-Reply-To: <200708131431.13088.max@love2party.net> References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <200708112129.29751.max@love2party.net> <20070811205437.GA24731@garage.freebsd.pl> <200708131431.13088.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070813172225.GB8819>