Date: Tue, 09 Apr 2002 23:41:29 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: callum.gibson@db.com Cc: hackers@FreeBSD.ORG Subject: Re: ipcrm/shmctl failure Message-ID: <3CB3DE99.316696E9@mindspring.com> References: <20020410031814.21717.qmail@merton.aus.deuba.com>
next in thread | previous in thread | raw e-mail | index | archive | help
callum.gibson@db.com wrote: > }> You could say that X11 shouldn't use SHMs the way it does now yeah. =) > }The real problem is that over the UNIX domain socket, it doesn't > }get client disconnect notificiations necessary for resource tracking, > }AND browser use of these resources is practically the degenerate case. > > I think you're right about the linux stuff. It looks that you _will_ get > an EINVAL on a valid shmid if it has already been marked for deletion > (but presumably still exists due to references). Using the -o to ipcs > I see there are existing references (why didn't anyone suggest that > before) - but these are by non existent processes. > > I'm now pretty sure this is caused by the linux implementation of > threads which uses multiple processes instead of a single proces. Now > vm_fork() (vm/vm_glue.c) calls shmfork which increments the shm ref count > for the forked process but this _shouldn't_ get called when rfork is > called with RFMEM (which is what linux_clone() does). So, turning to > the exit side of things, sys_exit() calls exit1() which only calls > shmexit to decrement the count if vm_refcnt == 1. Ok, rfork(RFMEM) > increments vm_refcnt in vm_fork(), and it may be decremented in > vmspace_unshare() or vmspace_free(). However as best I can see, nothing > in exit1() calls any vm stuff unless vm_refcnt is already 1. So unless > someone can point out where I've missed the call, I think the fix is > something like: [ ... ] This looks right, to me. 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. However... 1) This is actually simpler, since it avoids the need to check on the RFMEM case, when there is an out of order close 2) The System V shm case is special, in that the shared memory segments actually come out of the kernel virtual memory address space, not the process (there are good reasons for this, actually). > linux-mozilla would be a pretty heavy thread user. If only linux threads > was posix compliant, eh (I know Terry has commented on this before). If you scould send-pr this, I think it would be more likely to be committed (or send it to a committer you acn work with, like Alfred... 8-)). -- 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?3CB3DE99.316696E9>