[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