Re: [libvirt] [BUG] mlock support breakage
On Wed, 2017-03-15 at 08:59 +0100, Jiri Denemark wrote:
> > Removing all memory locking limits should be something
that
> > admins very carefully opt-in into, because of the potential
> > host DoS consequences. Certainly not the default.
>
> There's no opt-in with <locked/>, it is mandatory to increase
> the mlock limit. Asking users to do this themselves is only
> adding an extra step that's causing breakage right now.
... we could consider <locked/> to be the explicit request for
setting an infinite memory locking limit and letting users set a lower
limit with hard_limit if they want.
There are several other cases in which memory is locked implicitly and
we should definitely not set the unlimited default for them.
That would still be suboptimal because the risk involved in
allowing QEMU to allocate unlimited amounts of locked memory
might not be immediately apparent to the user, but at least
we would have an explicit opt-in (the presence of the
<locked/> element) and we would not lose the ability to set
the limit explicitly to a lower value, so it sounds like a
decent enough balance.
Anyone opposed to implementing it this way?
PS: Luiz, please check your MUA. It's messing with the
recipients in a way that makes me surprised messages
managed to get to the list at all.
--
Andrea Bolognani / Red Hat / Virtualization