From patchwork Thu Nov 19 18:18:22 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Babu Moger X-Patchwork-Id: 7659901 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E788A9F392 for ; Thu, 19 Nov 2015 18:18:42 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F38942061C for ; Thu, 19 Nov 2015 18:18:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8AE9C20462 for ; Thu, 19 Nov 2015 18:18:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758008AbbKSSSi (ORCPT ); Thu, 19 Nov 2015 13:18:38 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:48827 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757752AbbKSSSh (ORCPT ); Thu, 19 Nov 2015 13:18:37 -0500 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAJIIV6p013414 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Nov 2015 18:18:32 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAJIIUEJ000690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2015 18:18:31 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAJIIUOl021128; Thu, 19 Nov 2015 18:18:30 GMT Received: from ca-qasparc20.us.oracle.com (/10.147.24.73) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Nov 2015 10:18:30 -0800 From: Babu Moger To: bhelgaas@google.com Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, babu.moger@oracle.com Subject: [PATCH v3] pci: Limit VPD length for megaraid_sas adapter Date: Thu, 19 Nov 2015 10:18:22 -0800 Message-Id: <1447957102-184860-1-git-send-email-babu.moger@oracle.com> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1447257297-198460-1-git-send-email-babu.moger@oracle.com> References: <1447257297-198460-1-git-send-email-babu.moger@oracle.com> X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Reading or Writing of PCI VPD data causes system panic. We saw this problem by running "lspci -vvv" in the beginning. However this can be easily reproduced by running cat /sys/bus/devices/XX../vpd VPD length has been set as 32768 by default. Accessing vpd will trigger read/write of 32k. This causes problem as we could read data beyond the VPD end tag. Behaviour is un- predictable when this happens. I see some other adapter doing similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk for Broadcom 5708S")) I see there is an attempt to fix this right way. https://patchwork.ozlabs.org/patch/534843/ or https://lkml.org/lkml/2015/10/23/97 Tried to fix it this way, but problem is I dont see the proper start/end TAGs(at least for this adapter) at all. The data is mostly junk or zeros. This patch fixes the issue by setting the vpd length to 0x80. Signed-off-by: Babu Moger Reviewed-by: Khalid Aziz Changes since v2 -> v3 Changed the vpd length from 0 to 0x80 which leaves the option open for someone to read first few bytes. Changes since v1 -> v2 Removed the changes in pci_id.h. Kept all the vendor ids in quirks.c --- drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index b03373f..b8774e2 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2123,6 +2123,44 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev) DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching); /* + * A read/write to sysfs entry ('/sys/bus/pci/devices//vpd') + * will dump 32k of data. The default length is set as 32768. + * Reading a full 32k will cause an access beyond the VPD end tag. + * The system behaviour at that point is mostly unpredictable. + * Also I dont believe vendors have implemented this VPD headers properly. + * Atleast I dont see it in following megaraid sas controller. + * That is why adding the quirk here. + */ +static void quirk_megaraid_sas_limit_vpd(struct pci_dev *dev) +{ + if (dev->vpd) + dev->vpd->len = 0x80; +} + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, + quirk_megaraid_sas_limit_vpd); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, + quirk_megaraid_sas_limit_vpd); + +/* * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the * VPD end tag will hang the device. This problem was initially * observed when a vpd entry was created in sysfs