[libvirt] [BUG] mlock support breakage
Luiz Capitulino
lcapitulino at redhat.com
Wed Mar 22 12:54:40 UTC 2017
On Wed, 15 Mar 2017 10:11:50 +0100
Andrea Bolognani <abologna at redhat.com> wrote:
> 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?
Ping?
More information about the libvir-list
mailing list