linux-kernel - Re: MAP_POPULATE behavior change?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 May 2008 14:54:50 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
Cc:	lkml <linux-kernel@...r.kernel.org>, mk <michael.kerrisk@...il.com>
Subject: Re: MAP_POPULATE behavior change?

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@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/