DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A95A67E9FA
Subject: Re: [PATCH v2] KVM: kvm_io_bus_unregister_dev() should never fail
To: Dmitry Vyukov <dvyukov@google.com>,
        Marcelo Tosatti <mtosatti@redhat.com>
References: <20170323172419.21435-1-david@redhat.com>
 <20170323204247.GC27861@amt.cnet>
 <CACT4Y+Y9MoCVSf515_btVJn=X8kGbJNQA7ujB+XPk=UdcxKNqQ@mail.gmail.com>
Cc: KVM list <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
        =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        stable <stable@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        Cornelia Huck <cornelia.huck@de.ibm.com>
From: David Hildenbrand <david@redhat.com>
Organization: Red Hat GmbH
Message-ID: <0dd97243-db9b-4d22-970e-489d0f491851@redhat.com>
Date: Fri, 24 Mar 2017 09:55:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CACT4Y+Y9MoCVSf515_btVJn=X8kGbJNQA7ujB+XPk=UdcxKNqQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1536
Lines: 43


>>> -             return r;
>>> +     if (i == bus->dev_count)
>>> +             return;
>>>
>>>       new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) *
>>>                         sizeof(struct kvm_io_range)), GFP_KERNEL);
>>> -     if (!new_bus)
>>> -             return -ENOMEM;
>>> +     if (!new_bus)  {
>>> +             pr_err("kvm: failed to shrink bus, removing it completely\n");
>>> +             goto broken;
>>
>> The guest will fail in mysterious ways, if you do this (and
>> io_bus_unregister_dev can be called during runtime): in-kernel device
>> accesses will fail with unknown behaviour in the guest.

Actually, the next access to the BUS should result in -ENOMEM. And the
error message should be enough to then figure out what went wrong.
However, to hit this scenario at all feels very unlikely. So I would
like to avoid advanced allocation schemes.

>>
>> Can't you retry a handful of times with GFP_KERNEL before switching to GFP_ATOMIC?
>> (which in case fails the machine is likely to be crashing soon).
> 
> The process can run in a cgroup, then kmalloc failure has nothing to
> do with overall memory consumption. Machine can be perfectly fine.
> Also, this very process can be chosen as an OOM kill target, then it
> needs to gracefully deal with kmalloc failure and proceed to a
> termination point.
> Generally retrying something in a loop does not look like a solid plan
> to deal with errors.
> 

I agree, looping on memory allocations never feels like the right thing
to do.

-- 

Thanks,

David