Repeated similar panics on -STABLE

[Don Lewis]

On 18 Apr, Terry Lambert wrote:
> Since the thread occurred on -hackers, thought I'd post here, too.
> 
> The thread (see subject) around 02 Apr 2003 demonstrated a panic
> in kern_malloc.c in malloc() as a result in the increased default
> KVA space in the 4.x branch.
> 
> I just posted a patch to -stable.
> 
> If there is a committer interested in fixing this problem for
> people who doesn't read -stable, they may want to grab it and
> commit it.

The patch looks ok, but I don't understand the failure mechanism.  If
kbp->kb_next is initially NULL, then kmem_malloc() should get called. It
doesn't look possible for kmem_malloc() to return NULL in the !M_NOWAIT
case with the kmem_map.  It looks like kmem_malloc() will either retry
or panic.

I don't see how the kbp list could be refreshed and reemptied as you
suggested in a previous message, because we're protected by splmem()
except if kmem_malloc() blocks, and that can only happen before we put
the newly allocated memory on the kbp list.

Depending on how much you believe the line number reported by gdb, the
trap is caused by
	va = kbp->kb_next;
and not the following line:
	kbp->kb_next = ((struct freelist *)va)->next;
which would tend to make me think that kbp was somehow getting stomped
on.

Something else that bothers me is

>> fault virtual address   = 0x5cdd8000

If the trap is being caused by va being NULL, I'd expect the fault
adress to be 0x12 because the next member of struct freelist is at
offset 12, at least for the i386 architecture.