From owner-cvs-sys  Tue Aug  8 06:27:17 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id GAA28418
          for cvs-sys-outgoing; Tue, 8 Aug 1995 06:27:17 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id GAA28401
          ; Tue, 8 Aug 1995 06:26:55 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA09841; Tue, 8 Aug 1995 23:24:41 +1000
Date: Tue, 8 Aug 1995 23:24:41 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199508081324.XAA09841@godzilla.zeta.org.au>
To: bde@zeta.org.au, dyson@freefall.cdrom.com
Subject: Re: cvs commit: src/sys/i386/isa syscons.c
Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

>> I think M_WAITOK is no good for general use.  Using it safely seems to
>> _always_ require fairly tricky locking like we recently added to
>> ffs_vget().  If there is any chance that a subroutine of a syscall calls
>> ...
>> The unified buffer cache probably makes these races more common.
>> 
>It is very tricky to get the allocations correct, but the merged cache
>code does lock vnodes and check memory allocations.  Additionally, looking
>at the vfs_bio it does M_NOWAIT (or equiv vm_page_alloc).   (In fact,
>I have a deadlock free nfs_bio locking mechanism now, that I am experimenting
>with.)

My main point was that the problem potentially applies to all uses of
M_WAITOK.  There are currently 238 plus more in aliases.  5 out of 5
new ones are buggy.  I guess more than half of the others are buggy.

I didn't mean that the unified buffer cache has bugs.  Races should be
more common just because memory is more fully committed.

Bruce