Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1838990pxu; Thu, 17 Dec 2020 22:04:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJw/VzajI+3Pg+Gia40XWafwcH3UVk6xg5BFXj5Cq23b7p3SSGc+MyOiIDsgJvzGlv4xPkUU X-Received: by 2002:aa7:c3cd:: with SMTP id l13mr2758309edr.97.1608271482531; Thu, 17 Dec 2020 22:04:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608271482; cv=none; d=google.com; s=arc-20160816; b=A+iuKDFrzcn18Fwok1VZXV6k+aBDNgoj2Ey2OpLsOdd+RgNv6/0eROwvR+oJdGDa7/ 7D/KLtUvB1nurnO3lYdgOBlE20OuM+wYpqZFvdlI+goAIpojblwwi/XfpPynWXAfXIcW 9/IyNXxDHkUnX+nFhfb/7zROFXIUf4/g6CPkpEj1dfNeu2bc7sJysGIa4N56fMEdoo/U MSuzwhRZz4Te1Zq5j0IFHSUoeYPbmyQMbG/OIalKz6S6L+4/rnTspmZkngmHdENE8z9i j9aqHsKNmgMZZ0annnbvgnZNUX4fBdAGu9cH2KNvrMPxwrqY7Yo01dQhOD1KUX9LsLrD dvPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=W3K9g5CU7hwU8+Jg9zTN2uS8Y8hnE1/SYQTybtbXtH4=; b=LqK+PsDAq6nDBTK1Lx88phkKxR+8DPMdv9q7jIbHF8/QVTolmNHxilGA6wpD030o3+ cGuBR2NOMha1A8RODAaYI78WiX7uRYTwzXhaXUsPRsAdarEvVSXOHm4joG45pEWBVB8/ EcwrApp+SyTUh2aspI++XU1qtn/bZAFq+eH42238lKcC8C1Xsf3k1tgUdz3w9Yrvaow0 xP0mLFrnIz5dR790vgfmmCWKQ57rU1TNKOHxX9cIiwBLapuAVfSh1cUw+5AIsDqaY+Cz id5e0YjyquP0Sky+gqdeacN7DLYMmHvlj0I2JY61b2tAS4wZ5/c2g/Nx0vnog4RCRuwg qkKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r17si6040807edq.47.2020.12.17.22.04.19; Thu, 17 Dec 2020 22:04:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732480AbgLRGBo (ORCPT + 99 others); Fri, 18 Dec 2020 01:01:44 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:9538 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725870AbgLRGBn (ORCPT ); Fri, 18 Dec 2020 01:01:43 -0500 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Cxyrk026gzhrg4; Fri, 18 Dec 2020 14:00:22 +0800 (CST) Received: from DESKTOP-8RFUVS3.china.huawei.com (10.174.185.179) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Fri, 18 Dec 2020 14:00:50 +0800 From: Zenghui Yu To: , , , CC: , , Zenghui Yu Subject: [PATCH] genirq/msi: Initialize msi_alloc_info to zero for msi_prepare API Date: Fri, 18 Dec 2020 14:00:39 +0800 Message-ID: <20201218060039.1770-1-yuzenghui@huawei.com> X-Mailer: git-send-email 2.23.0.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.174.185.179] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since commit 5fe71d271df8 ("irqchip/gic-v3-its: Tag ITS device as shared if allocating for a proxy device"), some of the devices are wrongly marked as "shared" by the ITS driver on systems equipped with the ITS(es). The problem is that the @info->flags may not be initialized anywhere and we end up looking at random bits on the stack. That's obviously not good. The straightforward fix is to properly initialize msi_alloc_info inside the .prepare callback of affected MSI domains (its-pci-msi, its-platform-msi, etc). We can also perform the initialization in IRQ core layer for msi_domain_prepare_irqs() API and it looks much neater to me. Signed-off-by: Zenghui Yu --- This was noticed when I was playing with the assigned devices on arm64 and VFIO failed to enable MSI-X vectors for almost all VFs (CCed kvm list in case others will hit the same issue). It turned out that these VFs are marked as "shared" by mistake and have trouble with the following sequence: pci_alloc_irq_vectors(pdev, 1, 1, flag); pci_free_irq_vectors(pdev); pci_alloc_irq_vectors(pdev, 1, 2, flag); --> we can only get *one* vector But besides VFIO, I guess there are already some devices get into trouble at probe time and can't work properly. kernel/irq/msi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c index 2c0c4d6d0f83..dc0e2d7fbdfd 100644 --- a/kernel/irq/msi.c +++ b/kernel/irq/msi.c @@ -402,7 +402,7 @@ int __msi_domain_alloc_irqs(struct irq_domain *domain, struct device *dev, struct msi_domain_ops *ops = info->ops; struct irq_data *irq_data; struct msi_desc *desc; - msi_alloc_info_t arg; + msi_alloc_info_t arg = { }; int i, ret, virq; bool can_reserve; -- 2.19.1