Re: MAP_POPULATE behavior change?

[Nick Piggin]

On Mon, May 05, 2008 at 02:42:44PM +0200, Michael Kerrisk wrote:
> Hi Nick,
> 
> On Mon, May 5, 2008 at 2:23 PM, Nick Piggin <npiggin@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/