Re: MAP_POPULATE behavior change?

[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
--
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/