public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Timur Tabi <timur.tabi@ammasso.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: get_user_pages() and shared memory question
Date: Tue, 21 Jun 2005 13:21:40 -0500	[thread overview]
Message-ID: <42B85AB4.7030401@ammasso.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0506211840210.5784@goblin.wat.veritas.com>

Hugh Dickins wrote:

> It depends on what you mean by allocate and deallocate.  If the second
> process is attaching the same shared memory segment as the first process
> had attached, then yes, its buffer will contain those very pages which
> the driver erroneously failed to release.

No, I'm talking about when the first process completely destroys the shared memory segment 
so that it no longer exists.  No processes are attached to it, and any attempt to attach 
to it results in an error, because it doesn't exist.

In this case, when a process creates a new memory segment, I just want to know whether the 
pages with a non-zero refcount (because of the get_user_pages() call) can ever be used in 
a new shared memory segment.

I'm assuming the answer is no, because that would defeat the purpose of refcount (right?). 
  I've been looking at the code and reading books on the VM, but I get lost easily.  It 
appears that the function which allocates a page is shmem_alloc_page(), which calls 
alloc_page() to do the actual work.  If that's correct, is it possible for alloc_page() to 
return a page that has been previously "claimed" by get_user_pages()?  I'm looking at 
__alloc_pages(), and I don't see any calls to page_count(), so I guess there's some other 
mechanism (either in get_user_pages() or in the way the VM works) that prevents this 
possibility.  However, I'm getting dangerously close to my limit of understanding the 
Linux VM.

Thanks for replying to my message.  I really appreciate the help in understanding the 
Linux VM.

-- 
Timur Tabi
Staff Software Engineer
timur.tabi@ammasso.com

One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
      -- Ed Smylie, NASA engineer for Apollo 13

  reply	other threads:[~2005-06-21 18:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-21 15:10 get_user_pages() and shared memory question Timur Tabi
2005-06-21 17:33 ` Roland Dreier
2005-06-21 18:02 ` Hugh Dickins
2005-06-21 18:21   ` Timur Tabi [this message]
2005-06-21 19:38     ` Hugh Dickins
2005-06-21 19:43 ` Brice Goglin
2005-06-21 19:55   ` Timur Tabi

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=42B85AB4.7030401@ammasso.com \
    --to=timur.tabi@ammasso.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox