Re: [BUG] mlock support breakage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux