On Wed, 15 Mar 2017 10:11:50 +0100 Andrea Bolognani <abologna@xxxxxxxxxx> 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? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
