From admin@home.pl Sat Feb 20 05:35:42 1999
Return-Path: <admin@home.pl>
Received: from home.pl (unknown [195.205.230.39])
	by hub.freebsd.org (Postfix) with ESMTP id DDAB210E6B
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 20 Feb 1999 05:35:33 -0800 (PST)
	(envelope-from admin@home.pl)
Received: (from root@localhost)
	by home.pl (8.9.2/8.9.2) id OAA00416;
	Sat, 20 Feb 1999 14:33:34 +0100 (CET)
	(envelope-from admin)
Message-Id: <199902201333.OAA00416@home.pl>
Date: Sat, 20 Feb 1999 14:33:34 +0100 (CET)
From: steve@home.pl
Sender: admin@home.pl
Reply-To: steve@home.pl
To: FreeBSD-gnats-submit@freebsd.org
Subject: panic: cannot allocate pipe - out of kvm
X-Send-Pr-Version: 3.2

>Number:         10172
>Category:       kern
>Synopsis:       [panics] Kernel (esp kern/sys_pipe.c) dies on low kvm
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 20 10:30:03 PST 1999
>Closed-Date:    Sun Jun 02 04:51:20 PDT 2002
>Last-Modified:  Sun Jun 02 04:51:20 PDT 2002
>Originator:     System administrator
>Release:        FreeBSD 3.1-RELEASE i386
>Organization:
HomeNet
>Environment:
	FreeBSD 3.1-RELEASE, SMP, multiprocessor motherboard
	Under FreeBSD 3.0-RELEASE and 3.0-STABLE all works fine

>Description:
	panic: pipeinit: cannot allocate pipe -- out of kvm
	it's error message from kern/sys_pipe.c line 232

>How-To-Repeat:
	compile a kernel
	do more operations on files (for example move big directory
	structures under midc)

>Fix:
	i don't known ;-))

>Release-Note:
>Audit-Trail:

From: Alexander Langer <alex@cichlids.com>
To: freebsd-gnats-submit@freebsd.org, steve@home.pl
Cc:  
Subject: Re: kern/10172: panic: cannot allocate pipe - out of
Date: Sun, 21 Nov 1999 15:28:24 +0100 (CET)

 Does this problem still exist on recent releases of -stable or -current?
 If so, please give us more information about the problem
 and the error/panic.
 
 Thanks
 
 Alex
 
 
State-Changed-From-To: open->closed 
State-Changed-By: hoek 
State-Changed-When: Mon May 8 19:24:16 PDT 2000 
State-Changed-Why:  
BDE has noted that at the time, kern/sys_pipe.c was/is sloppy when 
it runs out of memory (msg-id: 
<Pine.BSF.4.10.9911220229070.7782-100000@alphplex.bde.org>).  A number 
of changes have been made to sys_pipe.c since then, although it's not 
clear that any of them necessarily fix this bug.  However, since this 
is for an old release, since there is no indication that it is still 
repeatable, and since the code in question has changed, I am going to 
close the PR.  If you are still experiencing problems, please file a 
new PR detailing the problems. 

State-Changed-From-To: closed->open 
State-Changed-By: hoek 
State-Changed-When: Sat May 13 04:27:38 PDT 2000 
State-Changed-Why:  
We'll leave this open for a while in hopes of implementing some grand 
type of solution. 


From: Bruce Evans <bde@zeta.org.au>
To: hoek@FreeBSD.org
Cc:  
Subject: Re: kern/10172
Date: Tue, 9 May 2000 22:28:40 +1000 (EST)

 > State-Changed-From-To: open->closed
 > State-Changed-By: hoek
 > State-Changed-When: Mon May 8 19:24:16 PDT 2000
 > State-Changed-Why: 
 > BDE has noted that at the time, kern/sys_pipe.c was/is sloppy when
 > it runs out of memory (msg-id:
 > <Pine.BSF.4.10.9911220229070.7782-100000@alphplex.bde.org>).  A number
 > of changes have been made to sys_pipe.c since then, although it's not
 > clear that any of them necessarily fix this bug.  However, since this
 
 The panic is still there.  It's for running out of kvm, which is probably
 fatal for other reasons.  To test running out of kvm, I think the
 namespace cache bug can be exploited, except under RELENG_3 which has
 the vfs.cache.maxaliases hack.  I'll remind phk and alfred.
 
 Bruce
 
 

From: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/10172
Date: Sat, 13 May 2000 07:32:40 -0400

 [verbatim from -arch list]
 
 ----- Forwarded message from Poul-Henning Kamp <phk@critter.freebsd.dk> -----
 
 To: arch@freebsd.org
 Subject: Re: vfs.cache.maxaliases 
 Date: Tue, 09 May 2000 14:48:59 +0200
 From: Poul-Henning Kamp <phk@critter.freebsd.dk>
 
 In message <Pine.BSF.4.21.0005092228470.7696-100000@besplex.bde.org>, Bruce Eva
 ns writes:
 
 >Did the user kmem exhaustion service in the name cache doesn't seem to be
 >fixed in RELENG_4 or -current.  Only RELENG_3 has vfs.cache.maxaliases.
 
 Right, it isn't, it's not fixed in RELENG_3 either but a big ugly
 roadblock has been put down for it.
 
 We currently have a variant of the problem affecting some machines:
 Imagine a 4GB RAM machine caching a lot of one-page vnodes -> we
 run out of KVM for the vnodes.
 
 I think the right solution consists of two things:
 
 1. A global kernel flag which tells us how we are doing KVM wise:
 
 	enum {KVM_OK, KVM_LOW, LVM_VERYLOW, KVM_EMPTY} kvm_state;
 
    This variable will be maintained by the VM system, and other
    subsystems can use it to determine their behaviour.
 
 2. An emergency call back list for when we are desparately low on KVM.
 
 
 For the namecache the right behaviour would then be:
 
    When adding a new entry:
 	   kvm_state == KVM_OK
 		business as ususal 
 	   kvm_state == KVM_LOW
 		free at least two entries and at least as many bytes
 		as we are going to allocate before adding a new entry.
 	   kvm_state == KVM_VERYLOW
 		free at least five entries, do not allocate new entry.
 	   kvm_state == KVM_EMPTY
 		free entire cache
 
    callback:
 	free entire cache
 
 The vnode cache can be made to gracefully react in a similar way.
 
 Such a scheme will allow us to gracefully avoid running out of KVM
 and at least it will survive all DoS attacks on the namecache which
 I am aware off.
 
 --
 Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 phk@FreeBSD.ORG         | TCP/IP since RFC 956
 FreeBSD coreteam member | BSD since 4.3-tahoe    
 Never attribute to malice what can adequately be explained by incompetence.
 
 
 To Unsubscribe: send mail to majordomo@FreeBSD.org
 with "unsubscribe freebsd-arch" in the body of the message
 
 ----- End forwarded message -----
 
 
 -- 
 Signature withheld by request of author.
 

From: Tim Vanderhoek <tim@localhost.nowhere>
To: freebsd-gnats-submit@FreeBSD.org, steve@home.pl
Cc: vanderh@ecf.toronto.edu
Subject: Re: kern/10172: [panics] Kernel (esp kern/sys_pipe.c)
Date: Tue, 16 May 2000 17:27:55 -0400 (EDT)

 See kern/10224, which adds little additional useful thought, but is
 a duplicate of the "sys_pipe.c eats lots of kvm" bug.
 
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Jan 20 08:47:02 PST 2002 
State-Changed-Why:  

Does this problem still exist in recent releases? There were a 
number of related changes to sys_pipe.c last year, so maybe this 
is fixed. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=10172 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Sun Jun 2 04:50:57 PDT 2002 
State-Changed-Why:  

Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=10172 
>Unformatted:
