linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Eli Cohen <mlxk@mellanox.co.il>, linux-kernel@vger.kernel.org
Subject: Re: locking user space memory in kernel
Date: 21 Mar 2004 10:18:38 -0800	[thread overview]
Message-ID: <52ptb62hdt.fsf@topspin.com> (raw)
In-Reply-To: <405DCDA1.3080008@colorfullife.com>

    Manfred> I think just get_user_pages() should be sufficient: the
    Manfred> pages won't be swapped out. You don't need to set
    Manfred> VM_LOCKED in vma->vm_flags to prevent the swap out. In
    Manfred> the worst case, the pte is cleared a that will cause a
    Manfred> soft page fault, but the physical address won't
    Manfred> change. Multiple get_user_pages() calls on overlapping
    Manfred> regions are ok, the page count is an atomic_t, at least
    Manfred> 24-bit large.

    Roland> There is one case that we ran into where the physical
    Roland> address can change: if a process does a fork() and then
    Roland> triggers COW.

    Manfred> You are right.  What should happen if there are
    Manfred> registered transfers during fork()?  Copy the pages
    Manfred> during the fork() syscall?

The current Mellanox InfiniBand driver goes to some trouble to mark
the memory being registered with VM_DONTCOPY.  This means the vmas
don't get copied into the child of a fork(), so the COW doesn't
happen.  However, this certainly leads to some quirks in semantics.
In particular, an application using fork() has to be careful that
registered memory doesn't share a page with something the child
process wants to use.

I don't think copying all the registered memory on fork() is feasible,
because it's going to kill performance (especially since exec() is
likely to immediately follow the fork() in the child).  Also, there
may not be enough memory around to copy everything.

Out of curiousity, what happens if I fork with pending AIO in the
current kernel?

 - Roland


  reply	other threads:[~2004-03-21 18:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-21 11:31 locking user space memory in kernel Manfred Spraul
2004-03-21 14:12 ` Manfred Spraul
2004-03-21 16:40 ` Roland Dreier
2004-03-21 17:15   ` Manfred Spraul
2004-03-21 18:18     ` Roland Dreier [this message]
2004-03-22 13:15       ` Eli Cohen
2004-03-22 15:22       ` Eli Cohen
2004-03-22 19:34         ` Manfred Spraul
  -- strict thread matches above, loose matches on Subject: below --
2004-04-08  6:20 Ross Dickson
2004-04-08  0:45 Libor Michalek
2004-04-08  5:22 ` Manfred Spraul
2004-03-21 11:18 Eli Cohen
2004-03-21 11:35 ` Arjan van de Ven

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=52ptb62hdt.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mlxk@mellanox.co.il \
    /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;
as well as URLs for NNTP newsgroup(s).