All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@osdl.org>
To: Neil Horman <nhorman@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] close race condition in shared memory mapping/unmapping
Date: Mon, 13 Sep 2004 14:01:01 -0700	[thread overview]
Message-ID: <20040913140101.S1973@build.pdx.osdl.net> (raw)
In-Reply-To: <4146041F.2040106@redhat.com>; from nhorman@redhat.com on Mon, Sep 13, 2004 at 04:33:35PM -0400

* 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
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

  parent reply	other threads:[~2004-09-13 21:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-13 20:33 [PATCH] close race condition in shared memory mapping/unmapping Neil Horman
2004-09-13 20:49 ` Felipe W Damasio
2004-09-13 20:54   ` Neil Horman
2004-09-13 21:01 ` Chris Wright [this message]
2004-09-14 11:48   ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040913140101.S1973@build.pdx.osdl.net \
    --to=chrisw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.