All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Dobson <colpatch@us.ibm.com>
To: linux-mm@kvack.org, William Lee Irwin III <wli@holomorphy.com>,
	"Martin J. Bligh" <mbligh@aracnet.com>
Subject: [question] shm_nattch in sys_shmat?
Date: Fri, 31 Jan 2003 14:35:38 -0800	[thread overview]
Message-ID: <3E3AFA3A.6050205@us.ibm.com> (raw)

Hello all!
	In case it wasn't obvious from the subject, I've got a question about a 
piece of code in ipc/shm.c:sys_shmat(), more specifically about the use 
of the shm_nattch counter.  This is supposed to be used to count the 
number of times the shared memory segment has been attatched to a 
processes adress space.  For example, shm_open & shm_mmap both increment 
shm_nattch, and shm_close decrements shm_nattch.  I would be inclined to 
think that sys_shmat should increment this counter, to keep track of a 
new attatchment of the shared segment to a processes adress space. 
sys_shmat, does in fact increment shm_nattch, but only to decrement it 
again a few lines later, as seen in this code snippet.  Can anyone 
please explain why this is?

 >	file = shp->shm_file;
 >	size = file->f_dentry->d_inode->i_size;
 >>>	shp->shm_nattch++;
 >	shm_unlock(shp);
 >
 >	down_write(&current->mm->mmap_sem);
 >	if (addr && !(shmflg & SHM_REMAP)) {
 >		user_addr = ERR_PTR(-EINVAL);
 >		if (find_vma_intersection(current->mm, addr, addr + size))
 >			goto invalid;
 >		/*
 >		 * If shm segment goes below stack, make sure there is some
 >		 * space left for the stack to grow (at least 4 pages).
 >		 */
 >		if (addr < current->mm->start_stack &&
 >		    addr > current->mm->start_stack - size - PAGE_SIZE * 5)
 >			goto invalid;
 >	}
 >
 >	user_addr = (void*) do_mmap (file, addr, size, prot, flags, 0);
 >
 >invalid:
 >	up_write(&current->mm->mmap_sem);
 >
 >	down (&shm_ids.sem);
 >	if(!(shp = shm_lock(shmid)))
 >		BUG();
 >>>	shp->shm_nattch--;
 >	if(shp->shm_nattch == 0 &&
 >	   shp->shm_flags & SHM_DEST)
 >		shm_destroy (shp);
 >	else
 >		shm_unlock(shp);
 >	up (&shm_ids.sem);

Thanks!

-Matt

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

             reply	other threads:[~2003-01-31 22:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-31 22:35 Matthew Dobson [this message]
2003-02-03 19:48 ` [question] shm_nattch in sys_shmat? Christoph Rohland
2003-02-03 23:43   ` Matthew Dobson

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=3E3AFA3A.6050205@us.ibm.com \
    --to=colpatch@us.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@aracnet.com \
    --cc=wli@holomorphy.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.