From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 20:35:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 664BD37B401 for ; Fri, 18 Apr 2003 20:35:53 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACA5243FDD for ; Fri, 18 Apr 2003 20:35:50 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3J3ZhXB015986; Fri, 18 Apr 2003 20:35:47 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304190335.h3J3ZhXB015986@gw.catspoiler.org> Date: Fri, 18 Apr 2003 20:35:43 -0700 (PDT) From: Don Lewis To: tlambert2@mindspring.com In-Reply-To: <3EA06987.3CF6D402@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 03:35:53 -0000 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.