From owner-freebsd-bugs Sat Oct 25 01:50:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA23116 for bugs-outgoing; Sat, 25 Oct 1997 01:50:04 -0700 (PDT) (envelope-from owner-freebsd-bugs) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA23109; Sat, 25 Oct 1997 01:50:02 -0700 (PDT) (envelope-from gnats) Date: Sat, 25 Oct 1997 01:50:02 -0700 (PDT) Message-Id: <199710250850.BAA23109@hub.freebsd.org> To: freebsd-bugs Cc: From: Matt Dillon Subject: Re: kern/4844: VM lookup, endless loop in vm_map_lookup_entry() Reply-To: Matt Dillon Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4844; it has been noted by GNATS. From: Matt Dillon To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/4844: VM lookup, endless loop in vm_map_lookup_entry() Date: Sat, 25 Oct 1997 01:42:18 -0700 (PDT) :> Both machines locked up in vm_map_lookup_entry() while trying :> to brelse/bfreekva/vm_map_delete (see below). One locked up :> from a SCSI interrupt doing the above sequence, the other locked :> up from system call. : :brelse/bfreekva have some problems. See PR4630, especially the followups. : :Bruce Assuming getnewbuf() isn't called from an interrupt, I believe I have a working solution. I'm going to test it a bit more. If it works out, i'll send you the diffs. It's really simple, I add another bufqueues[] element called QUEUE_DEFERED. brelse() puts the bp on QUEUE_DEFERED rather then QUEUE_EMPTY and does not call bfreekva(). getnewbuf() then moves everything from QUEUE_DEFERED to QUEUE_EMPTY and calls bfreekva() on it. The code mods are minor, and even pretty clean. I have a question, though, brelse() makes a call to allocbuf(bp, 0) under certain conditions. Do I have to worry about this too? -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!]