Re: MAP_POPULATE behavior change?
Michael Kerrisk
Ping!
Cheers,
Michael
-------- Original Message --------
Subject: MAP_POPULATE behavior change?
Date: Tue, 22 Apr 2008 15:16:19 +0200
From: Michael Kerrisk <mtk.ma...@gmail.com>
To: Nick Piggin <npi...@suse.de>
CC: lkml <linux-...@vger.kernel.org>, mk <michael...@gmail.com>
Hi Nick,
In 2.6.23, you had the commit below, which seems to have changed the
kernel-userland API.
Am I right to understand that with this patch MAP_POPULATE now also works with
MAP_PRIVATE mappings? (Formerly it only worked with MAP_SHARED mappings, but
some very quick testing suggests that MAP_POPULATE now also has an affect for
MAP_PRIVATE.)
Also, can you summarize the status of MAP_NONBLOCK? Is it now a no-op?
Cheers,
Michael
==
commit 54cb8821de07f2ffcd28c380ce9b93d5784b40d7
Author: Nick Piggin <npi...@suse.de>
Date: Thu Jul 19 01:46:59 2007 -0700
mm: merge populate and nopage into fault (fixes nonlinear)
Nonlinear mappings are (AFAIKS) simply a virtual memory concept that encodes
the virtual address -> file offset differently from linear mappings.
->populate is a layering violation because the filesystem/pagecache code
should need to know anything about the virtual memory mapping. The hitch here
is that the ->nopage handler didn't pass down enough information (ie. pgoff).
But it is more logical to pass pgoff rather than have the ->nopage function
calculate it itself anyway (because that's a similar layering violation).
Having the populate handler install the pte itself is likewise a nasty thing
to be doing.
This patch introduces a new fault handler that replaces ->nopage and
->populate and (later) ->nopfn. Most of the old mechanism is still in place
so there is a lot of duplication and nice cleanups that can be removed if
everyone switches over.
The rationale for doing this in the first place is that nonlinear mappings are
subject to the pagefault vs invalidate/truncate race too, and it seemed stupid
to duplicate the synchronisation logic rather than just consolidate the two.
After this patch, MAP_NONBLOCK no longer sets up ptes for pages present in
pagecache. Seems like a fringe functionality anyway.
NOPAGE_REFAULT is removed. This should be implemented with ->fault, and no
users have hit mainline yet.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
> Hey Nick,
>
> Ping!
>
> Cheers,
>
> Michael
>
>
> -------- Original Message --------
> Subject: MAP_POPULATE behavior change?
> Date: Tue, 22 Apr 2008 15:16:19 +0200
> From: Michael Kerrisk <mtk.ma...@gmail.com>
> To: Nick Piggin <npi...@suse.de>
> CC: lkml <linux-...@vger.kernel.org>, mk <michael...@gmail.com>
>
> Hi Nick,
>
> In 2.6.23, you had the commit below, which seems to have changed the
> kernel-userland API.
>
> Am I right to understand that with this patch MAP_POPULATE now also works with
> MAP_PRIVATE mappings? (Formerly it only worked with MAP_SHARED mappings, but
> some very quick testing suggests that MAP_POPULATE now also has an affect for
> MAP_PRIVATE.)
Yeah it should also set up anonymous mappings. Very observant :)
> Also, can you summarize the status of MAP_NONBLOCK? Is it now a no-op?
Yes, it is. The problem is you need to walk the page tables, and it
is fairly annoying to have to make a special case for that to be
non blocking (after just getting rid of the ->populate special case).
It is possible of course to implement. It might even be easier because
you could pass in a NONBLOCK flag to ->fault from get_user_pages... but
for now it is a noop.
Thanks,
Nick
Michael Kerrisk
On Mon, May 5, 2008 at 2:23 PM, Nick Piggin <npi...@suse.de> wrote:
> On Mon, Apr 28, 2008 at 02:07:17PM +0200, Michael Kerrisk wrote:
> > In 2.6.23, you had the commit below, which seems to have changed the
> > kernel-userland API.
> >
> > Am I right to understand that with this patch MAP_POPULATE now also works with
> > MAP_PRIVATE mappings? (Formerly it only worked with MAP_SHARED mappings, but
> > some very quick testing suggests that MAP_POPULATE now also has an affect for
> > MAP_PRIVATE.)
>
> Yeah it should also set up anonymous mappings. Very observant :)
Umm -- did it not work for anonymous *shared* mappings before? I
understood that it did.
> > Also, can you summarize the status of MAP_NONBLOCK? Is it now a no-op?
>
> Yes, it is.
Hmm -- going back and re-reading the code, there is:
if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK))
make_pages_present(addr, addr + len);
That means that MAP_NONBLOCK makes *MAP_POPULATE* a no-op. Was that intended?
Cheers,
Michael
Nick Piggin
> Hi Nick,
>
> On Mon, May 5, 2008 at 2:23 PM, Nick Piggin <npi...@suse.de> wrote:
> > On Mon, Apr 28, 2008 at 02:07:17PM +0200, Michael Kerrisk wrote:
>
> > > In 2.6.23, you had the commit below, which seems to have changed the
> > > kernel-userland API.
> > >
> > > Am I right to understand that with this patch MAP_POPULATE now also works with
> > > MAP_PRIVATE mappings? (Formerly it only worked with MAP_SHARED mappings, but
> > > some very quick testing suggests that MAP_POPULATE now also has an affect for
> > > MAP_PRIVATE.)
> >
> > Yeah it should also set up anonymous mappings. Very observant :)
>
> Umm -- did it not work for anonymous *shared* mappings before? I
> understood that it did.
Oh... yeah it would have. anonymous shared mappings aren't really anonymous
from the POV of most of mm/ :P
> > > Also, can you summarize the status of MAP_NONBLOCK? Is it now a no-op?
> >
> > Yes, it is.
>
> Hmm -- going back and re-reading the code, there is:
>
> if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK))
> make_pages_present(addr, addr + len);
>
> That means that MAP_NONBLOCK makes *MAP_POPULATE* a no-op. Was that intended?
Ah, my logic wasn't up to scratch there. Yes of course MAP_NONBLOCK is not
a noop, but it makes MAP_POPULATE into a noop. So it still guarantees
that the call will not block and that the kernel will make some kind of
best effort to populate the mapping... for some values of "some kind of"
(ie. "nothing" ;)).
It's done this way of course so it is still safe to call MAP_NONBLOCK if you
don't want to block, and thus everything stays backwards and forward
compatible.
Thanks,
Nick
Michael Kerrisk
> > > > Also, can you summarize the status of MAP_NONBLOCK? Is it now
> > > > a no-op?
> > >
> > > Yes, it is.
> >
> > Hmm -- going back and re-reading the code, there is:
> >
> > if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK))
> > make_pages_present(addr, addr + len);
> >
> > That means that MAP_NONBLOCK makes *MAP_POPULATE* a no-op.
> Was that intended?
>
>
> Ah, my logic wasn't up to scratch there. Yes of course MAP_NONBLOCK is not
> a noop, but it makes MAP_POPULATE into a noop. So it still guarantees
> that the call will not block and that the kernel will make some kind of
> best effort to populate the mapping... for some values of "some kind of"
> (ie. "nothing" ;)).
>
> It's done this way of course so it is still safe to call MAP_NONBLOCK if you
> don't want to block, and thus everything stays backwards and forward
> compatible.
Thanks.
Continuing on from there, what is the status of the flags argument for
remap_file_pages() now. the man page curently carries this text:
The flags argument has the same meaning as for mmap(2),
but all flags other than MAP_NONBLOCK are ignored.
My question is: is it still true that flags other than MAP_NONBLOCK
are ignored? A quick glance at the code leads me to suspect not.
(I'm not sure if you made the recent changes to that code or not?)
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html