From owner-freebsd-hackers Tue Apr 16 19: 0:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 9E07337B41C for ; Tue, 16 Apr 2002 19:00:18 -0700 (PDT) Received: from pool0108.cvx40-bradley.dialup.earthlink.net ([216.244.42.108] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xek4-0006W2-00; Tue, 16 Apr 2002 19:00:16 -0700 Message-ID: <3CBCD715.9E9B6971@mindspring.com> Date: Tue, 16 Apr 2002 18:59:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: callum.gibson@db.com Cc: hackers@FreeBSD.ORG Subject: Re: ipcrm/shmctl failure (fix NOT found) References: <20020417012241.13695.qmail@merton.aus.deuba.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG callum.gibson@db.com wrote: > tlambert2@mindspring.com writes: > }Heh. That's a Biiiiiiig snip. I had a huge caveat on the code > }doing what it did where it did it, if you'll remember. 8-). > > Sorry, Terry it was no slight on you (and it looked fine to me too). I just > wanted to get something in the list archives in case some poor sod decided > to search them and try it out. Also to warn against a simple MFC (though > people always test that stuff, don't they? :-) I just wanted to make sure that someone would not stop their back tracking. In my previous posting, I offered what I thought would be the correct approach to solving the problem: ] You'd actually think that not incrementing in the RFMEM case, but ] then decrementing if the RFMEM reference goes from 1->0 would be ] the correct thing to do. This should actually be a pretty trivial to fix. If you look in /sys/kern/kern_exec.c in exec_new_vmspace(), you'll see the proper way of exiting on the shm instance: if (vmspace->vm_refcnt == 1) { if (vmspace->vm_shm) shmexit(imgp->proc); ...in other words, the resource track exit does not occur until the reference count is about to go from 1->0. Note that there is an implicit race here, actually, between the reference and the detach, in which another instance could conceivably be created. 8-(. At this point, I think it would be wise to instrument rfork, fork, vm_fork, shmfork, and shmexit to see what's going on with your particular program. It may be that your program is reattaching an already attached shared memory segment, and expecting the behaviour to be sane. Really, the place to look for that would be in the Linux kernel sources, to see how it handled shares memory segments with Linux threads... it may be that it doesn't expect them to be attached, and that each thread is expected to do the attach. The above instrumentation points should tell you this. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message