Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault

[Vlastimil Babka]

On 06/15/2015 04:43 PM, Eric B Munson wrote:
> > Note that the semantic of MAP_LOCKED can be subtly surprising:
> >
> > "mlock(2) fails if the memory range cannot get populated to guarantee
> > that no future major faults will happen on the range.
> > mmap(MAP_LOCKED) on the other hand silently succeeds even if the
> > range was populated only
> > partially."
> >
> > ( from http://marc.info/?l=linux-mm&m=143152790412727&w=2 )
> >
> > So MAP_LOCKED can silently behave like MAP_LOCKONFAULT. While
> > MAP_LOCKONFAULT doesn't suffer from such problem, I wonder if that's
> > sufficient reason not to extend mmap by new mlock() flags that can
> > be instead applied to the VMA after mmapping, using the proposed
> > mlock2() with flags. So I think instead we could deprecate
> > MAP_LOCKED more prominently. I doubt the overhead of calling the
> > extra syscall matters here?
>
> We could talk about retiring the MAP_LOCKED flag but I suspect that
> would get significantly more pushback than adding a new mmap flag.

Oh no we can't "retire" as in remove the flag, ever. Just not continue 
the way of mmap() flags related to mlock().

> Likely that the overhead does not matter in most cases, but presumably
> there are cases where it does (as we have a MAP_LOCKED flag today).
> Even with the proposed new system calls I think we should have the
> MAP_LOCKONFAULT for parity with MAP_LOCKED.

I'm not convinced, but it's not a major issue.

> > > - mlock() takes a `flags' argument.  Presently that's
> > >    MLOCK_LOCKED|MLOCK_LOCKONFAULT.
> > >
> > > - munlock() takes a `flags' arument.  MLOCK_LOCKED|MLOCK_LOCKONFAULT
> > >    to specify which flags are being cleared.
> > >
> > > - mlockall() and munlockall() ditto.
> > >
> > >
> > > IOW, LOCKED and LOCKEDONFAULT are treated identically and independently.
> > >
> > > Now, that's how we would have designed all this on day one.  And I
> > > think we can do this now, by adding new mlock2() and munlock2()
> > > syscalls.  And we may as well deprecate the old mlock() and munlock(),
> > > not that this matters much.
> > >
> > > *should* we do this?  I'm thinking "yes" - it's all pretty simple
> > > boilerplate and wrappers and such, and it gets the interface correct,
> > > and extensible.
> >
> > If the new LOCKONFAULT functionality is indeed desired (I haven't
> > still decided myself) then I agree that would be the cleanest way.
>
> Do you disagree with the use cases I have listed or do you think there
> is a better way of addressing those cases?

I'm somewhat sceptical about the security one. Are security sensitive 
buffers that large to matter? The performance one is more convincing and 
I don't see a better way, so OK.

> > > What do others think?

--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html