[libvirt] [PATCH 8/8] docs: Improve documentation related to memory locking

Martin Kletzander mkletzan at redhat.com
Tue Mar 28 17:10:04 UTC 2017


On Tue, Mar 28, 2017 at 12:40:04PM -0400, Luiz Capitulino wrote:
>On Tue, 28 Mar 2017 18:26:12 +0200
>Andrea Bolognani <abologna at redhat.com> 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.
>

I must say I'm kinda on Luiz's side here.  It is clear what everything
does and how does it work and what are the risks.  The discouragement is
subjective *and* redundant as all the risks and technicalities are
explained.  If, for some admin/developer, "your machine may crash" is
not enough, but "your machine may crash, you should not do this" will
make everything rainbows and sunshine, then such person should rather be
user of its own system and not anything else.

>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170328/fc8603e4/attachment-0001.sig>


More information about the libvir-list mailing list