Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1010026imm; Wed, 13 Jun 2018 11:50:56 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLg0FoQu1j4+Qs8AAknW1WiV8bn02frmWjTYyAszWzfZI7IS3wJoF3UYmeTiYZwDtcQwhux X-Received: by 2002:a62:660a:: with SMTP id a10-v6mr6076651pfc.156.1528915856546; Wed, 13 Jun 2018 11:50:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528915856; cv=none; d=google.com; s=arc-20160816; b=hJ7Un9XvFcQ4aGB5CFTf0NvFEf0sjSiIpydKmKg6Q1lgLS/VVpVzp2dzwm75UN6TYp xQ73mz/h95ZPV6wmu+vr84y6RSq249c5Vg93suqYyN2zfLARiViyHLdLfYcTYRL35bGF D6SDRJVEDeleK7BxZNzZLwhg52v4WRm3YSEjciHSNpVJ3juuVlK+7qurkenSKiqeQITR n66n9oRIEVG22JQK4yh8Jxi1RRJxt2TnwygndKK5SwpruRrXn3hQB1PFFRp9glUZlPPo +DoDoMhuGwFUtWBcqmvfwee9PifWbogKZQIJeHbrIREuFXK9GKRKghljbwhHN5SAvQ2J 6Vrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=kw9AwNGTx5xpjk0JF7Iskad8Mz/iRt0YF2OrKb6UuZ4=; b=AABFzctEuxQosbSy73CNJ9zRxwwu6KieyYgb6z8VERJpBO6L4vFolQXaTi1Qk0vg4/ MYbbb07TcAqo20Yx989POvg7x0kdvakajKG6TDHdEYWwp2tNm1CYkalC7Rj6sKX8+jOc 4/3HcNJfjkPDjMuHtpcRwdesTPU7Ng4dJsPXqlH3uvrfmUIs1KwViruaXY0z7DVo7QJA YUP51ni1RLCO/leLzO4Nfp02ULA5HEXJf4a3BRwOyV4w8On02VNdbayf7wX44z4R0fJX mk+XMitrj5V8qi6QD3sqnX2Nbzkwa/lKVV6H43KG0faX3Gqv9ftfgfuS4RHoX+p47kH8 +4MA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i186-v6si3532095pfb.90.2018.06.13.11.50.42; Wed, 13 Jun 2018 11:50:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935333AbeFMSs4 (ORCPT + 99 others); Wed, 13 Jun 2018 14:48:56 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:49975 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935070AbeFMSsz (ORCPT ); Wed, 13 Jun 2018 14:48:55 -0400 Received: from [148.252.241.226] (helo=xylophone) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fTAp9-00065C-Kh; Wed, 13 Jun 2018 19:48:51 +0100 Message-ID: <1528915730.2289.166.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 119/268] xen/pirq: fix error path cleanup when binding MSIs From: Ben Hutchings To: Roger Pau Monne Cc: Greg Kroah-Hartman , LKML , stable , Hooman Mirhadi , Amit Shah , Boris Ostrovsky , Juergen Gross , Sasha Levin Date: Wed, 13 Jun 2018 19:48:50 +0100 In-Reply-To: <1528914431.2289.163.camel@citrix.com> References: <1528914431.2289.163.camel@citrix.com> Organization: Codethink Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-02-28 at 09:19 +0000, Roger Pau Monne wrote: > From: Roger Pau Monne > > [ Upstream commit 910f8befdf5bccf25287d9f1743e3e546bcb7ce0 ] > > Current cleanup in the error path of xen_bind_pirq_msi_to_irq is > wrong. First of all there's an off-by-one in the cleanup loop, which > can lead to unbinding wrong IRQs. > > Secondly IRQs not bound won't be freed, thus leaking IRQ numbers. > > Note that there's no need to differentiate between bound and unbound > IRQs when freeing them, __unbind_from_irq will deal with both of them > correctly. It appears to me that it is safe to call __unbind_from_irq() after xen_irq_info_common_setup() fails, but *not* if the latter hasn't been called at all. In that case the IRQ type will still be set to IRQT_UNBOUND and this will trigger the BUG_ON() in __unbind_from_irq(). [...] > --- a/drivers/xen/events/events_base.c > +++ b/drivers/xen/events/events_base.c > @@ -764,8 +764,8 @@ out: >   mutex_unlock(&irq_mapping_update_lock); >   return irq; >  error_irq: > - for (; i >= 0; i--) > - __unbind_from_irq(irq + i); > + while (nvec--) > + __unbind_from_irq(irq + nvec); If nvec > 1, and xen_irq_info_pirq_setup() fails for i != nvec - 1, then we reach here without having called xen_irq_info_common_setup() for all these IRQs. In that case, I think we will still want to call xen_free_irq() for all IRQs. So maybe the fix would be to remove the BUG_ON() in __unbind_from_irq()? Ben. >   mutex_unlock(&irq_mapping_update_lock); >   return ret; >  } -- Ben Hutchings, Software Developer   Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom