Re: [PATCH] limited support for non-root mlock()

[Samuel Thibault]

Hello,

Justus Winter, le Wed 08 Jul 2015 16:22:28 +0200, a écrit :
> You talked about that in your FOSDEM talk, right?

Yes, although since I hadn't had any look at it at the time, I hadn't
realized that passing host==NULL wasn't an option (since we need a port
to make the RPC on anyway).

> Ever since I thought that managing this in userspace is the better
> solution,

Well, the actual enforcement has to be done where default paging
happens, otherwise it'd be a security issue.

> > I had to introduce a newer RPC since the existing vm_wire RPC is
> > done on the privileged host port.
> 
> Alternatively, you could re-purpose the existing RPC `vm_wire',
> changing the type of its first argument from `host_priv_t' to `host_t'
> (this is backwards compatible as the privileged host control port is
> also a host port), and changing the behavior slightly depending on
> whether the user passed the priv port or a normal host port.

Ah, right.

> > It for now allows 64KiB mlocked memory per task (the default Linux
> > value).
> 
> Isn't a per-process limit rather pointless?  I thought Linux limit is
> per-user.

On Linux it's per process too, changing ulimit -l in a process won't
affect another process.

The issue with mlocked memory is mostly about eating non-pageable
memory. Creating processes already eats non-pageable memory anyway, so
it doesn't buy much to eat a bit more non-pageable memory per process.

> Oh, and why did you chose `mach4.defs' to add a new RPC?  I mean, it
> doesn't really matter, the Mach API isn't properly grouped into
> protocols, and there is just one huge dispatcher, but I thought we put
> new definitions into `gnumach.defs'.

I don't really know actually. I'd tend to think that mach4.defs is for
newer RPCs which make sense on oldish Mach, while gnumach.defs is for
GNU-introduced features, but I really don't know the rules.

Samuel