On Tue, 28 Mar 2017 18:26:12 +0200 Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > On Tue, 2017-03-28 at 09:43 -0400, Luiz Capitulino wrote: > > > Another stab at it (which plugs into my original version): > > > > > > [...] remove the limit on locked memory altogether. Thus, > > > enabling this option opens up to a potential security risk: > > > the host will be unable to reclaim the locked memory back > > > from the guest when it's running out of memory, which means > > > a malicious guest allocating large amounts of locked memory > > > could cause a denial-of-service attach on the host. Because > > > of this, using the option is discouraged unless your [...] > > > > > > Does it look reasonable? > > > > That looks fine, although I'd drop "discouraged" because that's > > not helpful to those who must use the feature. I think it's better > > to objectively explain what the problems are and how to prevent or > > mitigate them. That's what I tried to do in my paragraph. > > The strong wording is intentional: we really, really don't > want people to enable this unless their setup can't work > without it. I don't see how using strong wording is going to be helpful to users who need to use the feature. The documentation should be helpful and technically clear. It should instruct, not cause fear. Your last paragraph is an improvement, but I really think this mindset against <locked/> is very wrong. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
