Date: Sun, 11 Oct 2009 21:38:33 -0700 From: Harsha <inpcb.harsha@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org, net@freebsd.org Subject: Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] Message-ID: <e1b1c5880910112138x1b46ff0eo39c10691a978c164@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.0910112126050.48605@fledge.watson.org> References: <e1b1c5880910111226o65e0d1a9va975f4cd837271bb@mail.gmail.com> <alpine.BSF.2.00.0910112126050.48605@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Robert, On Sun, Oct 11, 2009 at 1:30 PM, Robert Watson <rwatson@freebsd.org> wrote: > Giant is a bit special in that the long-term sleep code in the kernel kno= ws > to drop it when sleeping, and re-acquire when waking up. =A0So, unlike al= l > other mutexes, it should be OK to hold it in this case, as Giant will sim= ply > get dropped if the kernel has to sleep waiting on a sleepable lock. =A0Th= is is > because, historically in FreeBSD 3.x/4.x, the kernel was protected by a > single spinlock, which would get released whenever the kernel stopped > executing, such as during an I/O sleep. =A0On the whole, Giant has disapp= eared > from the modern kernel, but where it is used, it retains those curious > historic properties. > > To break things down a bit further, IFNET_WLOCK is, itself, a bit special= : > notice that in FreeBSD 8, it's actually two locks, a sleep lock, and a > mutex, which must both be acquired exclusively to ensure mutual exclusion= . > if_alloc() and associated calls are also sleepable because they perform > potentially sleeping memory allocation (M_WAITOK), so it's an invariant o= f > any code calling interface allocation that it must be able to tolerate a > sleep. Thanks a lot for the clarification. I had assumed that the lock was non-sleepable looking at this log - Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r =3D 0 (0xc0f63464) locked @ /usr/src/sys/net/if.c:409 > Do you have a copy of the stack trace and fault information handy? =A0In = my > experience, a NULL pointer deref or other page fault in the locking code = for > a global lock is almost always corrupted thread state, perhaps due to > tripping over another thread having locked a corrupted/freed/uninitialize= d > lock. =A0We might be able to track that down by tracing other threads tha= t > were in execution at the time of the panic. I just tried the textdump feature and I think its an awesome tool. Here is ddb.txt- http://docs.google.com/View?id=3Ddddwnxfj_0dh4x58hc And msgbuf.txt- http://docs.google.com/View?id=3Ddddwnxfj_1cnmrb8fw For some reason the output of show alllocks is not written into ddb.txt, though I have increased the buffer size to 2MB. Thanks, Harsha
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e1b1c5880910112138x1b46ff0eo39c10691a978c164>