From he@pvv.ntnu.no  Fri Jan 14 04:01:55 2000
Return-Path: <he@pvv.ntnu.no>
Received: from verden.pvv.ntnu.no (verden.pvv.ntnu.no [129.241.210.224])
	by hub.freebsd.org (Postfix) with SMTP id 0EC7314EB0
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 14 Jan 2000 04:01:54 -0800 (PST)
	(envelope-from he@pvv.ntnu.no)
Received: (qmail 60815 invoked by uid 13841); 14 Jan 2000 12:01:52 -0000
Message-Id: <20000114120152.60814.qmail@verden.pvv.ntnu.no>
Date: 14 Jan 2000 12:01:52 -0000
From: he@runit.no (Havard Eidnes)
Sender: he@pvv.ntnu.no
Reply-To: he@runit.no
To: FreeBSD-gnats-submit@freebsd.org
Subject: Incorrect SysV SHM segment accounting by async I/O helper procs
X-Send-Pr-Version: 3.2

>Number:         16122
>Category:       kern
>Synopsis:       Incorrect SysV SHM segment accounting by async I/O helper procs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 14 04:10:00 PST 2000
>Closed-Date:    Mon Jul 23 17:35:39 PDT 2001
>Last-Modified:  Mon Jul 23 17:38:30 PDT 2001
>Originator:     Havard Eidnes
>Release:        FreeBSD 3.3-RELEASE i386
>Organization:
RUNIT AS
>Environment:
	"Standard" i386 machine running 3.3-RELEASE.

>Description:
	Only the first async I/O helper process releases the SystemV
	shared memory segments inherited from the parent process.  All
	async I/O helper processes end up calling shmfork() (implicitly
	via rfork()), but exit without doing shmexit(), causing shared
	memory segment reference counts not to be updated correctly.

	This causes shared memory segments to get an ever increasing
	reference count, preventing their removal from the system even
	though the processes which caused the reference count to be
	increased are no longer present.

>How-To-Repeat:
	Use SystemV shared memory segments and asynchronous I/O
	in the same process.  Note in "ipcs -mobp" output that
	the reference count of the segments increase over time
	as this process is run several times.

	(Sorry, no code here to reproduce the problem.)

>Fix:
	Not only the first async I/O helper process should get rid of its
	SystemV shared memory segments inherited from the parent process.

	Perusal of cvsweb seems to indicate that this problem
	is also present in the FreeBSD 3.4 release.

--- /sys/kern/vfs_aio.c.dist	Sun Aug 29 18:26:12 1999
+++ /sys/kern/vfs_aio.c	Thu Jan 13 14:24:10 2000
@@ -618,44 +618,49 @@
 	 * We manage to create only one VM space for all AIOD processes.
 	 * The VM space for the first AIOD created becomes the shared VM
 	 * space for all of them.  We add an additional reference count,
 	 * even for the first AIOD, so the address space does not go away,
 	 * and we continue to use that original VM space even if the first
 	 * AIOD exits.
 	 */
 	if ((aiovm = aiovmspace) == NULL) {
 		aiovmspace = myvm;
 		myvm->vm_refcnt++;
 		/*
 		 * Remove userland cruft from address space.
 		 */
 		if (myvm->vm_shm)
 			shmexit(mycp);
 		pmap_remove_pages(&myvm->vm_pmap, 0, USRSTACK);
 		vm_map_remove(&myvm->vm_map, 0, USRSTACK);
 		myvm->vm_tsize = 0;
 		myvm->vm_dsize = 0;
 		myvm->vm_ssize = 0;
 	} else {
 		aiovm->vm_refcnt++;
+		/*
+		 * Remove userland cruft from address space.
+		 */
+		if (myvm->vm_shm)
+			shmexit(mycp);
 		mycp->p_vmspace = aiovm;
 		pmap_activate(mycp);
 		vmspace_free(myvm);
 		myvm = aiovm;
 	}
 
 	if (mycp->p_textvp) {
 		vrele(mycp->p_textvp);
 		mycp->p_textvp = NULL;
 	}
 
 	/*
 	 * Allocate and ready the aio control info.  There is one
 	 * aiop structure per daemon.
 	 */
 	aiop = zalloc(aiop_zone);
 	aiop->aioproc = mycp;
 	aiop->aioprocflags |= AIOP_FREE;
 	TAILQ_INIT(&aiop->jobtorun);
 
 	/*
 	 * Place thread (lightweight process) onto the AIO free thread list



>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: mike 
State-Changed-When: Sat Jul 21 11:37:23 PDT 2001 
State-Changed-Why:  

Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16122 

From: Mike Barcroft <mike@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/16122: Incorrect SysV SHM segment accounting by async I/O helper procs
Date: Mon, 23 Jul 2001 20:33:47 -0400

 Adding to Audit-Trail.
 
 ----- Forwarded message from Havard Eidnes <he@uninett.no> -----
 
 X-UIDL: 3d2173d338c5c22dd6bbd858ea583252
 Delivered-To: mike@freebsd.org
 Date: Mon, 23 Jul 2001 22:46:00 +0200 (CEST)
 To: mike@FreeBSD.org
 Cc: freebsd-bugs@FreeBSD.org
 Subject: Re: kern/16122: Incorrect SysV SHM segment accounting by async I/O
  helper procs
 From: Havard Eidnes <he@uninett.no>
 In-Reply-To: <200107211837.f6LIbZV27241@freefall.freebsd.org>
 X-Mailer: Mew version 1.95b124 on Emacs 20.7 / Mule 4.0 (HANANOEN)
 X-MIME-Autoconverted: from quoted-printable to 8bit by coffee.q9media.com id f6NL76n72735
 
 > Does this problem still occur in newer versions of FreeBSD,
 > such as 4.3-RELEASE?
 
 I'm sorry, but I'm no longer in a position where I'm able to test that
 in any reasonably easy way (I beleive 4.0 was just about coming out
 when I reported the problem, and the code related to this problem was
 changed significantly in the then-new version).
 
 Sorry to not be able to be more helpful.
 
 - Hvard
 
 ----- End forwarded message -----
State-Changed-From-To: feedback->closed 
State-Changed-By: mike 
State-Changed-When: Mon Jul 23 17:35:39 PDT 2001 
State-Changed-Why:  

The originator is no longer able to test this problem in a newer 
version of FreeBSD.  As the originator points out, there have been 
a lot of changes to the relevant code, so I believe it's likely 
this problem has been solved.  If it hasn't been solved in a newer 
version of FreeBSD, a new PR should be opened. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16122 
>Unformatted:
