lkml.org 
[lkml]   [2005]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
Roland Dreier <roland@topspin.com> wrote:
>
> Timur> With mlock(), we don't need to use get_user_pages() at all.
> Timur> Arjan tells me the only time an mlocked page can move is
> Timur> with hot (un)plug of memory, but that isn't supported on
> Timur> the systems that we support. We actually prefer mlock()
> Timur> over get_user_pages(), because if the process dies, the
> Timur> locks automatically go away too.
>
> There actually is another way pages can move, with both
> get_user_pages() and mlock(): copy-on-write after a fork(). If
> userspace does a fork(), then all PTEs are marked read-only, and if
> the original process touches the page after the fork(), a new page
> will be allocated and mapped at the original virtual address.

Do we care about that? A straightforward scenario under which this can
happen is:

a) app starts some read I/O in an asynchronous manner
b) app forks
c) child writes to one of the pages which is still under read I/O
d) the read I/O completes
e) the child is left with the old data plus the child's modification instead
of the new data

which is a very silly application which is giving itself unpredictable
memory contents anyway.

I assume there's a more sensible scenario?
-
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/

\
 
 \ /
  Last update: 2005-04-25 23:00    [W:0.089 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site