Date: Mon, 13 Aug 2007 14:31:06 +0200 From: Max Laier <max@love2party.net> To: Pawel Jakub Dawidek <pjd@freebsd.org> 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: <200708131431.13088.max@love2party.net> In-Reply-To: <20070811205437.GA24731@garage.freebsd.pl> References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <200708112129.29751.max@love2party.net> <20070811205437.GA24731@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1983264.hrjkTlodga Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 August 2007, Pawel Jakub Dawidek wrote: > On Sat, Aug 11, 2007 at 09:29:23PM +0200, Max Laier wrote: > > On Saturday 11 August 2007, Kris Kennaway wrote: > > > On Sun, Aug 12, 2007 at 02:22:35AM +0800, Rong-en Fan wrote: > > > > I'm running 7.0-CURRENT as of yesterday, and it's very easy > > > > to make it panic: > > > > > > > > Sleeping thread (tid 100065, pid 1066) owns a non-sleepable lock > > > > sched_switch(c50a1600,0,1,1c7a7e4,4217e5,...) at > > > > sched_switch+0x190 mi_switch(1,0) at mi_switch+0x13f > > > > sleepq_switch(c50a1600,0,c078a4e2,21b,c07e3820,...) at > > > > sleepq_switch+0x87 sleepq_wait(c07e3820,0,c0770b7e,3,0,...) at > > > > sleepq_wait+0x36 _sx_xlock_hard(c07e3820,c50a1600,0,0,0,...) at > > > > _sx_xlock_hard+0x21d > > > > fr_checknatout(f9c7a8d0,f9c7a8cc,64,c57ad900,c4de7400,...) at > > > > fr_checknatout+0x29d > > > > fr_check(c8cc4644,14,c4de7400,1,f9c7a9b4,...) at fr_check+0x9b1 > > > > fr_check_wrapper(0,f9c7a9b4,c4de7400,2,c54dab28,...) at > > > > fr_check_wrapper+0x3f > > > > pfil_run_hooks(c08057c0,f9c7aa4c,c4de7400,2,c54dab28,...) at > > > > pfil_run_hooks+0x74 ip_output(c8cc4600,0,f9c7aa10,0,0,...) at > > > > ip_output+0x913 > > > > tcp_output(cae322d0,cb277200,0,0,0,...) at tcp_output+0x1106 > > > > tcp_usr_send(c51e7318,0,cb277200,0,0,...) at tcp_usr_send+0x240 > > > > kern_sendfile(c50a1600,f9c7acfc,0,0,0,...) at > > > > kern_sendfile+0x1037 > > > > sendfile(c50a1600,f9c7acfc,20,16,f9c7ad2c,...) at sendfile+0xa8 > > > > syscall(f9c7ad38) at syscall+0x315 > > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > > --- syscall (393, FreeBSD ELF32, sendfile), eip =3D 0x28290bff, esp > > > > =3D 0xbfbfc6ac, ebp =3D 0xbfbfe718 --- > > > > > > What is the lock it holds, and where is it acquired? > > > > My bet is on the pfil rwlock - accquired in pfil_run_hooks and > > tcbinfo / inp mtxs from tcp_output. Nothing in the transmission path > > must use sx locks. I keep on telling that. > > 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() ? 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. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1983264.hrjkTlodga Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGwE8RXyyEoT62BG0RAjEEAJ9cYzhsSPGPtxo6lWYWzi6BgK3R4QCfeMzy xF3FUNd1f8yPxqqXWAQGdKU= =W9Ca -----END PGP SIGNATURE----- --nextPart1983264.hrjkTlodga--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708131431.13088.max>