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
