Date: Fri, 18 Apr 2003 20:35:43 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: tlambert2@mindspring.com Cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE Message-ID: <200304190335.h3J3ZhXB015986@gw.catspoiler.org> In-Reply-To: <3EA06987.3CF6D402@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304190335.h3J3ZhXB015986>