Date: Tue, 16 Apr 2002 18:59:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: callum.gibson@db.com Cc: hackers@FreeBSD.ORG Subject: Re: ipcrm/shmctl failure (fix NOT found) Message-ID: <3CBCD715.9E9B6971@mindspring.com> References: <20020417012241.13695.qmail@merton.aus.deuba.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CBCD715.9E9B6971>