From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34537 "EHLO
        mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S1752109AbdCXJex (ORCPT
        <rfc822;stable@vger.kernel.org>); Fri, 24 Mar 2017 05:34:53 -0400
Received: from pps.filterd (m0098414.ppops.net [127.0.0.1])
        by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2O9Y3VD064146
        for <stable@vger.kernel.org>; Fri, 24 Mar 2017 05:34:05 -0400
Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])
        by mx0b-001b2d01.pphosted.com with ESMTP id 29cmcb005k-1
        (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)
        for <stable@vger.kernel.org>; Fri, 24 Mar 2017 05:34:04 -0400
Received: from localhost
        by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
        for <stable@vger.kernel.org> from <cornelia.huck@de.ibm.com>;
        Fri, 24 Mar 2017 09:34:00 -0000
Date: Fri, 24 Mar 2017 10:33:55 +0100
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
        Marcelo Tosatti <mtosatti@redhat.com>,
        KVM list <kvm@vger.kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Radim =?UTF-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        stable <stable@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: kvm_io_bus_unregister_dev() should never fail
In-Reply-To: <0dd97243-db9b-4d22-970e-489d0f491851@redhat.com>
References: <20170323172419.21435-1-david@redhat.com>
        <20170323204247.GC27861@amt.cnet>
        <CACT4Y+Y9MoCVSf515_btVJn=X8kGbJNQA7ujB+XPk=UdcxKNqQ@mail.gmail.com>
        <0dd97243-db9b-4d22-970e-489d0f491851@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20170324103355.73bb95ec.cornelia.huck@de.ibm.com>
Sender: stable-owner@vger.kernel.org
List-ID: <stable.vger.kernel.org>

On Fri, 24 Mar 2017 09:55:15 +0100
David Hildenbrand <david@redhat.com> wrote:

> 
> >>> -             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.

Hopefully, an admin will look at the logs :)

But yes, the patch should have caught all issues in the host, and the
guest will basically be presented with broken "hardware".

> However, to hit this scenario at all feels very unlikely. So I would
> like to avoid advanced allocation schemes.

Agreed, spending too much time on complex recovery scenarios is
overkill for this unlikely case.