Re: [RFC 1/3] mm: mmap make MAP_LOCKED really mlock semantic

[Michal Hocko]

On Tue 28-04-15 16:10:01, Andrew Morton wrote:
> On Tue, 28 Apr 2015 14:11:49 +0200 Michal Hocko <mhocko@xxxxxxx> wrote:
> 
> > The man page however says
> > "
> > MAP_LOCKED (since Linux 2.5.37)
> >       Lock the pages of the mapped region into memory in the manner of
> >       mlock(2).  This flag is ignored in older kernels.
> > "
> 
> I'm trying to remember why we implemented MAP_LOCKED in the first
> place.  Was it better than mmap+mlock in some fashion?
> 
> afaict we had a #define MAP_LOCKED in the header file but it wasn't
> implemented, so we went and wired it up.  13 years ago:
> https://lkml.org/lkml/2002/9/18/108

Yeah I have encountered this one while digging though the history as
well but there was no real usecase described - except "it doesn't work
currently".

The only sensible usecase I was able to come up with was a userspace
fault handling when we need to mmap and lock the faulting address in an
atomic way so that other threads cannot possibly leak data to the swap.
These guys can live with the current implementation, though.

I do not really believe that 2 instead of 1 syscall really justifies the
complexity.

> Anyway...  the third way of doing this is to use plain old mmap() while
> mlockall(MCL_FUTURE) is in force.  Has anyone looked at that, checked
> that the behaviour is sane and compared it with the mmap+mlock
> behaviour, the MAP_LOCKED behaviour and the manpages?

AFAICS this will behave the same way as mmap(MAP_LOCKED). VMA will be
marked VM_LOCKED but the popullation might fail for the very same
reason.

-- 
Michal Hocko
SUSE Labs
--
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/