From patchwork Tue Aug 9 10:09:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 73533 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp403672qga; Tue, 9 Aug 2016 03:09:36 -0700 (PDT) X-Received: by 10.98.205.6 with SMTP id o6mr168625437pfg.37.1470737376640; Tue, 09 Aug 2016 03:09:36 -0700 (PDT) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id h2si42017402pfe.212.2016.08.09.03.09.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Aug 2016 03:09:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bX3xd-0002ew-4D; Tue, 09 Aug 2016 10:08:37 +0000 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bX3xW-0002Tk-6K for linux-arm-kernel@lists.infradead.org; Tue, 09 Aug 2016 10:08:32 +0000 Received: by mail-wm0-x232.google.com with SMTP id o80so23734380wme.1 for ; Tue, 09 Aug 2016 03:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=atUmPTRCvAm6Jp9WCs1hqBQejsaYzfB998mPjAg4Wdw=; b=dgHwtqYEWfFJ0wLxaJ7AkphKH8/kUUDTgRMF9E6LBYlrqQ1ZZQAHvxPlMP8SXiewHQ o0WWebjlc1NgnX2UQgOWoUBcDhWboKoYfVF46mhDX25D7uUVDfLkbaFLv9jjlUbOKl4h NaoquTivnBWiKuuQN4qUBqO74AK/3yznm5jus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=atUmPTRCvAm6Jp9WCs1hqBQejsaYzfB998mPjAg4Wdw=; b=Rx64P86iIiZdqGhOMA9g3OdQm/9KxmIbsYAhkGF3DiM3YIA3RlESdZq7npaJBpYM0b RsxPUYZpB5QmKQljSqPClK7/4Us8lytZNrGYSdblgTQzxtfj22dCf4FC+1pg4rG3eWAv IwKH5iv9VrS9pYeNi6uAuq2HK11UEirlH+X1P5ohNIxwnxv/fAfxqOBc3z9o7xL6H34p ithd3q4vc2GAlL9FaxW2AN0oe9yD7YWJu4WCPOLLg7CNX+wAqSwGa/aBEVoqioovk0gF 5MRCRVqDIfl2t2iZDI/MbDvBW6zJKC4QqvAg1xWsMk+sJzBwh0diaQfCW/Mg/OrySLmD 5olQ== X-Gm-Message-State: AEkoouslFEEfXxrgkKdJL+31jTbjJPyoAlw2nIOZ+ZVQoEaoMUAiiwQGkKeb+//J3+EPatcc X-Received: by 10.28.194.195 with SMTP id s186mr21967798wmf.48.1470737288295; Tue, 09 Aug 2016 03:08:08 -0700 (PDT) Received: from localhost ([94.18.191.146]) by smtp.gmail.com with ESMTPSA id a203sm3110721wma.0.2016.08.09.03.08.07 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 09 Aug 2016 03:08:07 -0700 (PDT) Date: Tue, 9 Aug 2016 12:09:56 +0200 From: Christoffer Dall To: Andre Przywara Subject: Re: [PATCH v2 1/3] KVM: arm64: vgic-its: Handle errors from vgic_add_lpi Message-ID: <20160809100956.GB9175@cbox> References: <20160803161325.14933-1-christoffer.dall@linaro.org> <20160803161325.14933-2-christoffer.dall@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160809_030830_536689_3FE4EABD X-CRM114-Status: GOOD ( 29.12 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2a00:1450:400c:c09:0:0:0:232 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On Mon, Aug 08, 2016 at 12:00:50PM +0100, Andre Przywara wrote: > Hi, > > On 03/08/16 17:13, Christoffer Dall wrote: > > During low memory conditions, we could be dereferencing a NULL pointer > > when vgic_add_lpi fails to allocate memory. > > > > Consider for example this call sequence: > > > > vgic_its_cmd_handle_mapi > > itte->irq = vgic_add_lpi(kvm, lpi_nr); > > Ouch! Thanks for catching this unhandled error return! > > > update_lpi_config(kvm, itte->irq, NULL); > > ret = kvm_read_guest(kvm, propbase + irq->intid > > ^^^^ > > kaboom? > > > > Instead, return an error pointer from vgic_add_lpi and check the return > > value from its single caller. > > > > Signed-off-by: Christoffer Dall > > --- > > Changes since v1: > > - Don't errornously get an extra kref refernce for the struct vgic_irq > > - Don't rework the entire error handling of the function, but follow > > what Marc suggested he prefers based on his fixup patch. > > virt/kvm/arm/vgic/vgic-its.c | 18 ++++++++++++++---- > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > > index 07411cf..424f7a5 100644 > > --- a/virt/kvm/arm/vgic/vgic-its.c > > +++ b/virt/kvm/arm/vgic/vgic-its.c > > @@ -51,7 +51,7 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid) > > > > irq = kzalloc(sizeof(struct vgic_irq), GFP_KERNEL); > > if (!irq) > > - return NULL; > > + return ERR_PTR(-ENOMEM); > > > > INIT_LIST_HEAD(&irq->lpi_list); > > INIT_LIST_HEAD(&irq->ap_list); > > @@ -693,10 +693,11 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its, > > u32 device_id = its_cmd_get_deviceid(its_cmd); > > u32 event_id = its_cmd_get_id(its_cmd); > > u32 coll_id = its_cmd_get_collection(its_cmd); > > - struct its_itte *itte; > > + struct its_itte *itte, *new_itte = NULL; > > struct its_device *device; > > struct its_collection *collection, *new_coll = NULL; > > int lpi_nr; > > + struct vgic_irq *irq; > > > > device = find_its_device(its, device_id); > > if (!device) > > @@ -720,7 +721,7 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its, > > > > itte = find_itte(its, device_id, event_id); > > if (!itte) { > > - itte = kzalloc(sizeof(struct its_itte), GFP_KERNEL); > > + new_itte = itte = kzalloc(sizeof(struct its_itte), GFP_KERNEL); > > Nit: Aren't double assignments frowned upon in the kernel? > Seems like it is accoding to CodingStyle, although it can be found numerous places in the code base. But you're right, let's follow the official style. > > if (!itte) { > > if (new_coll) > > vgic_its_free_collection(its, coll_id); > > @@ -733,7 +734,16 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its, > > > > itte->collection = collection; > > itte->lpi = lpi_nr; > > - itte->irq = vgic_add_lpi(kvm, lpi_nr); > > + > > + irq = vgic_add_lpi(kvm, lpi_nr); > > + if (IS_ERR(irq)) { > > + if (new_coll) > > + vgic_its_free_collection(its, coll_id); > > + kfree(new_itte); > > But at this point we already have added that ITTE to the > device->itt_head, haven't we? > Since we hold the its_lock, would a simple: > > if (new_itte) { > list_del(&itte->itte_list); > kfree(new_itte); > } > > suffice to fix this? > hmm, it would be good to call its_free_itte for this. But then that would put a reference on an IRQ, which wouldn't necessarily have been taken. That could be reworked by changing its_free_itte like this: If not, I don't understand how you can just assign the irq field on the itte without putting whatever IRQ there may already be held with a reference there. Can you explain me the flow of how an itte is allocated, but not assigned an IRQ, and then later found in vgic_its_cmd_handle_mapi? > > + return PTR_ERR(irq); > > + } > > + itte->irq = irq; > > + > > update_affinity_itte(kvm, itte); > > > > /* > > > Thanks, -Christoffer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c index 424f7a5..6342c92 100644 --- a/virt/kvm/arm/vgic/vgic-its.c +++ b/virt/kvm/arm/vgic/vgic-its.c @@ -502,7 +502,8 @@ static void its_free_itte(struct kvm *kvm, struct its_itte *itte) list_del(&itte->itte_list); /* This put matches the get in vgic_add_lpi. */ - vgic_put_irq(kvm, itte->irq); + if (iite->irq) + vgic_put_irq(kvm, itte->irq); kfree(itte); } But this makes me wonder how we're really dealing with reference counts in the case where you find an itte and don't need to allocate one. Would this BUG_ON ever fire?: diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c index 424f7a5..a33fbf1 100644 --- a/virt/kvm/arm/vgic/vgic-its.c +++ b/virt/kvm/arm/vgic/vgic-its.c @@ -730,6 +730,8 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its, itte->event_id = event_id; list_add_tail(&itte->itte_list, &device->itt_head); + } else { + BUG_ON(itte->irq); } itte->collection = collection;