From owner-freebsd-bugs  Tue Feb  2 12:20:06 1999
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA26716
          for freebsd-bugs-outgoing; Tue, 2 Feb 1999 12:20:06 -0800 (PST)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26697
          for <freebsd-bugs@FreeBSD.org>; Tue, 2 Feb 1999 12:20:04 -0800 (PST)
          (envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.2/8.9.2) id MAA48571;
	Tue, 2 Feb 1999 12:20:01 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA26033;
          Tue, 2 Feb 1999 12:14:08 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199902022014.MAA26033@hub.freebsd.org>
Date: Tue, 2 Feb 1999 12:14:08 -0800 (PST)
From: templin@erg.sri.com
To: freebsd-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: www-1.0
Subject: kern/9883: MGET()(and variants) return NULL with M_WAIT flag; system crashes!
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         9883
>Category:       kern
>Synopsis:       MGET()(and variants) return NULL with M_WAIT flag; system crashes!
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb  2 12:20:01 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     Fred L. Templin
>Release:        2.2.7-19981122-SNAP
>Organization:
SRI International (The ANCORS Project)
>Environment:
FreeBSD sequoia.csl.sri.com 2.2.7-19981122-SNAP FreeBSD 2.2.7-19981122-SNAP #3:
Fri Jan 29 23:21:23 PST 1999     livio@sequoia.csl.sri.com:/usr/src/sys/compile/
EMERALD  i386
>Description:
(This problem was discovered during research ativities with the ANCORS
Project. Project information is at:  http://www.csl.sri.com/ancors)


We have a system which periodically runs out of mbuf's. (The nature
of the mbuf leak is beyond the scope of this problem report.) When
the 'mb_map' gets depleted, the kernel routines 'm_get()', 'MGET()'
and 'MGETHDR()' can return NULL *even when the caller has set the
M_WAIT flag*. But, there are numerous instances in the kernel in
which callers fail to check the return code and simply begin
referencing what they believe to be a valid mbuf. In our case,
the routine 'nfs_rephead()' is referencing a NULL mbuf pointer
returned from MGETHDR(), causing the system to panic with a
'page fault' trap.   
>How-To-Repeat:
Insert an artificial mbuf leak into the kernel. Configure the machine
as an NFS server and have some NFS activity going on before triggering
the mbuf leak. A crash out of the NFS code should eventually result
after the mb_map has been depleted by the leak.
>Fix:
Search out all instances in the kernel in which the return code from
the MGET() variants (with the M_WAIT flag set) is not checked. Check
the return code and handle the condition of a NULL mbuf pointer in the
appropriate way in each instance. Numerous examples which fail to check
the return code are in the kernel NFS code in: /usr/src/sys/nfs, but
there are many other instances scattered throughout the kernel. This
all assumes that returning NULL with the M_WAIT flag is a reasonable
thing to do. Since so much existing code seems to assume that setting
the M_WAIT flag will always result in a valid mbuf return, perhaps
allowing a NULL return is a bad thing to do in the first place... 
>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message