Date: Sat, 25 Oct 1997 01:50:02 -0700 (PDT) From: Matt Dillon <dillon@best.net> To: freebsd-bugs Subject: Re: kern/4844: VM lookup, endless loop in vm_map_lookup_entry() Message-ID: <199710250850.BAA23109@hub.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR kern/4844; it has been noted by GNATS.
From: Matt Dillon <dillon@best.net>
To: Bruce Evans <bde@zeta.org.au>
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.
<dillon@best.net>
[always include a portion of the original email in any response!]
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710250850.BAA23109>