Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/786364/?format=api
{ "id": 786364, "url": "http://patchwork.ozlabs.org/api/patches/786364/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20170710202319.22110-7-jacob.e.keller@intel.com/", "project": { "id": 46, "url": "http://patchwork.ozlabs.org/api/projects/46/?format=api", "name": "Intel Wired Ethernet development", "link_name": "intel-wired-lan", "list_id": "intel-wired-lan.osuosl.org", "list_email": "intel-wired-lan@osuosl.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20170710202319.22110-7-jacob.e.keller@intel.com>", "list_archive_url": null, "date": "2017-07-10T20:23:10", "name": "[v3,07/16] fm10k: don't loop while resetting VFs due to VFLR event", "commit_ref": null, "pull_url": null, "state": "accepted", "archived": false, "hash": "df58155ab17970dec242338c3af7e7597c294b71", "submitter": { "id": 9784, "url": "http://patchwork.ozlabs.org/api/people/9784/?format=api", "name": "Jacob Keller", "email": "jacob.e.keller@intel.com" }, "delegate": { "id": 68, "url": "http://patchwork.ozlabs.org/api/users/68/?format=api", "username": "jtkirshe", "first_name": "Jeff", "last_name": "Kirsher", "email": "jeffrey.t.kirsher@intel.com" }, "mbox": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20170710202319.22110-7-jacob.e.keller@intel.com/mbox/", "series": [], "comments": "http://patchwork.ozlabs.org/api/patches/786364/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/786364/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<intel-wired-lan-bounces@osuosl.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Received": [ "from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3x5xVp2Cn4z9s3T\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 11 Jul 2017 06:23:30 +1000 (AEST)", "from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id E20998880C;\n\tMon, 10 Jul 2017 20:23:28 +0000 (UTC)", "from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id tm-FgW40gXLe; Mon, 10 Jul 2017 20:23:28 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 51DB1887BC;\n\tMon, 10 Jul 2017 20:23:28 +0000 (UTC)", "from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 3C0521C4120\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tMon, 10 Jul 2017 20:23:23 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 1AEA82FFCD\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tMon, 10 Jul 2017 20:23:23 +0000 (UTC)", "from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id hoN6uZJsRnvx for <intel-wired-lan@lists.osuosl.org>;\n\tMon, 10 Jul 2017 20:23:22 +0000 (UTC)", "from mga14.intel.com (mga14.intel.com [192.55.52.115])\n\tby silver.osuosl.org (Postfix) with ESMTPS id 64C5D2FFBA\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tMon, 10 Jul 2017 20:23:22 +0000 (UTC)", "from fmsmga004.fm.intel.com ([10.253.24.48])\n\tby fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t10 Jul 2017 13:23:21 -0700", "from jekeller-desk.amr.corp.intel.com (HELO\n\tjekeller-desk.jekeller.internal) ([134.134.177.230])\n\tby fmsmga004.fm.intel.com with ESMTP; 10 Jul 2017 13:23:21 -0700" ], "X-Virus-Scanned": [ "amavisd-new at osuosl.org", "amavisd-new at osuosl.org" ], "X-Greylist": "domain auto-whitelisted by SQLgrey-1.7.6", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.40,342,1496127600\"; d=\"scan'208\";a=\"285198851\"", "From": "Jacob Keller <jacob.e.keller@intel.com>", "To": "jtkirhse@osuosl.org, Intel Wired LAN <intel-wired-lan@lists.osuosl.org>", "Date": "Mon, 10 Jul 2017 13:23:10 -0700", "Message-Id": "<20170710202319.22110-7-jacob.e.keller@intel.com>", "X-Mailer": "git-send-email 2.13.0.615.gb09ed6e59a40", "In-Reply-To": "<20170710202319.22110-1-jacob.e.keller@intel.com>", "References": "<20170710202319.22110-1-jacob.e.keller@intel.com>", "Cc": "jekeller@osuosl.org", "Subject": "[Intel-wired-lan] [PATCH v3 07/16] fm10k: don't loop while\n\tresetting VFs due to VFLR event", "X-BeenThere": "intel-wired-lan@osuosl.org", "X-Mailman-Version": "2.1.18-1", "Precedence": "list", "List-Id": "Intel Wired Ethernet Linux Kernel Driver Development\n\t<intel-wired-lan.osuosl.org>", "List-Unsubscribe": "<https://lists.osuosl.org/mailman/options/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>", "List-Archive": "<http://lists.osuosl.org/pipermail/intel-wired-lan/>", "List-Post": "<mailto:intel-wired-lan@osuosl.org>", "List-Help": "<mailto:intel-wired-lan-request@osuosl.org?subject=help>", "List-Subscribe": "<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "7bit", "Errors-To": "intel-wired-lan-bounces@osuosl.org", "Sender": "\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>" }, "content": "We've always had a really weird looping construction for resetting VFs.\nWe read the VFLRE register and reset the VF if the corresponding bit is\nset, which makes sense. However we loop continuously until we no longer\nhave any bits left unset. At first this makes sense, as a sort of \"keep\ntrying until we succeed\" concept.\n\nUnfortunately this causes a problem if we happen to surprise remove\nwhile this code is executing, because in this case we'll always read all\n1s for the VFLRE register. This results in a hard lockup on the CPU\nbecause the loop will never terminate.\n\nBecause our own reset function will clear the VFLR event register\nalways, (except when we've lost PCIe link obviously) there is no real\nreason to loop. In practice, we'll loop over once and find that no VFs\nare pending anymore.\n\nLets just check once. Since we're clear the notification when we reset\nthere's no benefit to the loop. Additionally, there shouldn't be a race\nas future VLFRE events should trigger an interrupt. Additionally, we\ndidn't warn or do anything in the looped case anyways.\n\nSigned-off-by: Jacob Keller <jacob.e.keller@intel.com>\n---\n drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 24 +++++++++++-------------\n 1 file changed, 11 insertions(+), 13 deletions(-)", "diff": "diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c\nindex dfc88a463735..03897720bf0b 100644\n--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c\n+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c\n@@ -66,23 +66,21 @@ s32 fm10k_iov_event(struct fm10k_intfc *interface)\n \t\tgoto read_unlock;\n \n \t/* read VFLRE to determine if any VFs have been reset */\n-\tdo {\n-\t\tvflre = fm10k_read_reg(hw, FM10K_PFVFLRE(1));\n-\t\tvflre <<= 32;\n-\t\tvflre |= fm10k_read_reg(hw, FM10K_PFVFLRE(0));\n+\tvflre = fm10k_read_reg(hw, FM10K_PFVFLRE(1));\n+\tvflre <<= 32;\n+\tvflre |= fm10k_read_reg(hw, FM10K_PFVFLRE(0));\n \n-\t\ti = iov_data->num_vfs;\n+\ti = iov_data->num_vfs;\n \n-\t\tfor (vflre <<= 64 - i; vflre && i--; vflre += vflre) {\n-\t\t\tstruct fm10k_vf_info *vf_info = &iov_data->vf_info[i];\n+\tfor (vflre <<= 64 - i; vflre && i--; vflre += vflre) {\n+\t\tstruct fm10k_vf_info *vf_info = &iov_data->vf_info[i];\n \n-\t\t\tif (vflre >= 0)\n-\t\t\t\tcontinue;\n+\t\tif (vflre >= 0)\n+\t\t\tcontinue;\n \n-\t\t\thw->iov.ops.reset_resources(hw, vf_info);\n-\t\t\tvf_info->mbx.ops.connect(hw, &vf_info->mbx);\n-\t\t}\n-\t} while (i != iov_data->num_vfs);\n+\t\thw->iov.ops.reset_resources(hw, vf_info);\n+\t\tvf_info->mbx.ops.connect(hw, &vf_info->mbx);\n+\t}\n \n read_unlock:\n \trcu_read_unlock();\n", "prefixes": [ "v3", "07/16" ] }