From owner-freebsd-commit  Tue Aug  8 04:29:16 1995
Return-Path: commit-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id EAA22145
          for commit-outgoing; Tue, 8 Aug 1995 04:29:16 -0700
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id EAA22017
          for cvs-sys-outgoing; Tue, 8 Aug 1995 04:27:51 -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 EAA21996
          ; Tue, 8 Aug 1995 04:27:20 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA04961; Tue, 8 Aug 1995 21:22:21 +1000
Date: Tue, 8 Aug 1995 21:22:21 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199508081122.VAA04961@godzilla.zeta.org.au>
To: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com,
        dyson@freefall.cdrom.com
Subject: Re: cvs commit: src/sys/i386/isa syscons.c
Sender: commit-owner@FreeBSD.org
Precedence: bulk

>  Modified:    sys/i386/isa  syscons.c
>  Log:
>  Fixed a problem that malloc(..,..,M_NOWAIT) was being called without checking
>  for return values.  It just so happens that in the cases where it is likely
>  to fail, it is okay to change the M_NOWAIT to M_WAITOK -- and all will
>  be well.  This problem was manfest as a panic very regularly on a 4MB
>  system right after bootup.

Actually it isn't really OK to simply substitute M_NOWAIT with M_WAITOK.
If one of the malloc()s in scioctl() sleeps, then another process may
run and use the half-allocated resources.  If one of the malloc()s in in
scioctl() or scopen() sleeps, then another process may run and repeat the
ioctl and (at best) allocate the resources twice.

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
malloc(..., M_WAIT_OK), then must be done to prevent the syscall being
reentered or to support reentrancy, and all resource that might be used
or change while malloc() is sleeping have to be locked down and/or
checked after waking up.

The unified buffer cache probably makes these races more common.

scioctl() is also missing necessary spltty() locking.  What happens if a
character is echoed while the history buffer is being resized? ...

Bruce