Messages in this thread | | | Date | Tue, 14 Sep 2004 07:48:20 -0400 | From | Neil Horman <> | Subject | Re: [PATCH] close race condition in shared memory mapping/unmapping |
| |
Chris Wright wrote: > * Neil Horman (nhorman@redhat.com) wrote: > >>Hey all- >> Found this the other day poking through the ipc code. There appears to >>be a race condition in the counter that records how many processes are >>accessing a given shared memory segment. In most places the shm_nattch >>variable is protected by the shm_ids.sem semaphore, but there are a few >>openings which appear to be able to allow a corruption of this variable >>when run on SMP systems. I've attached a patch to 2.6.9-rc2 for review. >> The locking may be a little over-aggressive (I was following examples >>from other points in this file), but I figure better safe than sorry :). > > > Are you sure you've got this right? I thought that the shmid_kernel > struct protects shm_nattch with a local (per structure) lock which is > embedded in kern_ipc_perm. Did you find shm_nattch changes w/out > shm_lock/shm_unlock around it? I believe shm_ids.sem is protecting the > id allocation, not per object data such as shm_nattch. > > thanks, > -chris You're right, its not correct. I'm sorry. I'm looking into a locking bug in 2.4, which does its ipc locking for shared memory very differently. Since the shared memory code looks simmilar in 2.6, I was making the assumption that the change applied upstram as well, but I don't think thats the case after looking more carefully. My bad. Neil
-- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |