Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c]

Hi Robert,

On Sun, Oct 11, 2009 at 1:30 PM, Robert Watson <rwatson_at_freebsd.org> wrote:
> Giant is a bit special in that the long-term sleep code in the kernel knows
> to drop it when sleeping, and re-acquire when waking up.  So, unlike all
> other mutexes, it should be OK to hold it in this case, as Giant will simply
> get dropped if the kernel has to sleep waiting on a sleepable lock.  This 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.  On the whole, Giant has disappeared
> 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 of
> 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 = 0 (0xc0f63464) locked _at_
/usr/src/sys/net/if.c:409

> Do you have a copy of the stack trace and fault information handy?  In 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/uninitialized
> lock.  We might be able to track that down by tracing other threads that
> 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=dddwnxfj_0dh4x58hc

And msgbuf.txt-
http://docs.google.com/View?id=dddwnxfj_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