[{"id":1761998,"web_url":"http://patchwork.ozlabs.org/comment/1761998/","msgid":"<26D9FDECA4FBDD4AADA65D8E2FC68A4A10EA9742@ORSMSX104.amr.corp.intel.com>","list_archive_url":null,"date":"2017-09-01T21:35:04","subject":"Re: [Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock\n\tduring\tNVM update","submitter":{"id":66945,"url":"http://patchwork.ozlabs.org/api/people/66945/","name":"Bowers, AndrewX","email":"andrewx.bowers@intel.com"},"content":"> -----Original Message-----\n> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On\n> Behalf Of Jacob Keller\n> Sent: Friday, September 1, 2017 1:43 PM\n> To: Intel Wired LAN \n> Cc: Stefan Assmann \n> Subject: [Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock during\n> NVM update\n> \n> From: Anjali Singhai Jain \n> \n> X722 devices use the AdminQ to access the NVM, and this requires taking the\n> AdminQ lock. Because of this, we lock the AdminQ during i40e_read_nvm(),\n> which is also called in places where the lock is already held, such as the\n> firmware update path which wants to lock once and then unlock when\n> finished after performing several tasks.\n> \n> Although this should have only affected X722 devices, commit\n> 96a39aed25e6 (\"i40e: Acquire NVM lock before reads on all devices\",\n> 2016-12-02) added locking for all NVM reads, regardless of device family.\n> \n> This resulted in us accidentally causing NVM acquire timeouts on all devices,\n> causing failed firmware updates which left the eeprom in a corrupt state.\n> \n> Create unsafe non-locked variants of i40e_read_nvm_word and\n> i40e_read_nvm_buffer, __i40e_read_nvm_word and\n> __i40e_read_nvm_buffer respectively. These variants will not take the NVM\n> lock and are expected to only be called in places where the NVM lock is\n> already held if needed.\n> \n> Since the only caller of i40e_read_nvm_buffer() was in such a path, remove\n> it entirely in favor of the unsafe version. If necessary we can always add it\n> back in the future.\n> \n> Additionally, we now need to hold the NVM lock in i40e_validate_checksum\n> because the call to i40e_calc_nvm_checksum now assumes that the NVM\n> lock is held. We can further move the call to read\n> I40E_SR_SW_CHECKSUM_WORD up a bit so that we do not need to acquire\n> the NVM lock twice.\n> \n> This should resolve firmware updates and also fix potential raise that could\n> have caused the driver to report an invalid NVM checksum upon driver load.\n> \n> Reported-by: Stefan Assmann \n> Fixes: 96a39aed25e6 (\"i40e: Acquire NVM lock before reads on all devices\",\n> 2016-12-02)\n> Signed-off-by: Anjali Singhai Jain \n> Signed-off-by: Jacob Keller \n> ---\n> \n> This is a more complete version of the patch suggested by Stefan, found at\n> https://patchwork.ozlabs.org/patch/808699/ and it should be able to avoid\n> needing the 2nd patch in his series, which reverted a workqueue change.\n> The code is slightly refactored from what he suggested, and also includes the\n> i40e_nvm_read_buffer() function, as well as fixing up the issues in\n> i40e_validate_checksum().\n> \n> Stefan, can you let me know if this works for you? I didn't have any issues,\n> but I'd like to confirm this fix is acceptable to you.\n> \n> drivers/net/ethernet/intel/i40e/i40e_nvm.c | 102 ++++++++++++++------\n> ---\n> drivers/net/ethernet/intel/i40e/i40e_prototype.h | 2 -\n> 2 files changed, 62 insertions(+), 42 deletions(-)\n\nTested-by: Andrew Bowers ","headers":{"Return-Path":"","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"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\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 3xkXb349SRz9sPt\n\tfor ;\n\tSat, 2 Sep 2017 07:35:11 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 046EA882BA;\n\tFri, 1 Sep 2017 21:35:10 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 5Mzn7obVBeDi; Fri, 1 Sep 2017 21:35:08 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 286CD88115;\n\tFri, 1 Sep 2017 21:35:08 +0000 (UTC)","from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id 4FF5C1C143E\n\tfor ;\n\tFri, 1 Sep 2017 21:35:07 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 4971487FA2\n\tfor ;\n\tFri, 1 Sep 2017 21:35:07 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id hZEDZvSD1_yl for ;\n\tFri, 1 Sep 2017 21:35:05 +0000 (UTC)","from mga14.intel.com (mga14.intel.com [192.55.52.115])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id CCF9E882C3\n\tfor ;\n\tFri, 1 Sep 2017 21:35:05 +0000 (UTC)","from fmsmga002.fm.intel.com ([10.253.24.26])\n\tby fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t01 Sep 2017 14:35:05 -0700","from orsmsx104.amr.corp.intel.com ([10.22.225.131])\n\tby fmsmga002.fm.intel.com with ESMTP; 01 Sep 2017 14:35:04 -0700","from orsmsx156.amr.corp.intel.com (10.22.240.22) by\n\tORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Fri, 1 Sep 2017 14:35:04 -0700","from orsmsx104.amr.corp.intel.com ([169.254.4.142]) by\n\tORSMSX156.amr.corp.intel.com ([169.254.8.89]) with mapi id\n\t14.03.0319.002; Fri, 1 Sep 2017 14:35:04 -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.41,459,1498546800\"; d=\"scan'208\";\n\ta=\"1213627095\"","From":"\"Bowers, AndrewX\" ","To":"Intel Wired LAN ","Thread-Topic":"[Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock\n\tduring\tNVM update","Thread-Index":"AQHTI2LqOZ4rVXXdX06sZ67Yo8SjCKKgjXAQ","Date":"Fri, 1 Sep 2017 21:35:04 +0000","Message-ID":"<26D9FDECA4FBDD4AADA65D8E2FC68A4A10EA9742@ORSMSX104.amr.corp.intel.com>","References":"<20170901204249.3835-1-jacob.e.keller@intel.com>","In-Reply-To":"<20170901204249.3835-1-jacob.e.keller@intel.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODUzYzIxMjEtYmJlYS00MDhkLWI4ZjQtYzNkN2MwZWUzMGNhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkdQU0l4VFI0XC84MG5INmFBWDhVdGVMSEV6S3NXb3B2eTVVUHBEZE53T3dNPSJ9","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[10.22.254.139]","MIME-Version":"1.0","Subject":"Re: [Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock\n\tduring\tNVM update","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","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1762218,"web_url":"http://patchwork.ozlabs.org/comment/1762218/","msgid":"<63fe2862-d5f7-8ad5-a171-a1a3af89a1bb@kpanic.de>","list_archive_url":null,"date":"2017-09-03T05:34:42","subject":"Re: [Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock\n\tduring NVM update","submitter":{"id":7508,"url":"http://patchwork.ozlabs.org/api/people/7508/","name":"Stefan Assmann","email":"sassmann@kpanic.de"},"content":"On 01.09.2017 22:42, Jacob Keller wrote:\n> From: Anjali Singhai Jain \n> \n> X722 devices use the AdminQ to access the NVM, and this requires taking\n> the AdminQ lock. Because of this, we lock the AdminQ during\n> i40e_read_nvm(), which is also called in places where the lock is\n> already held, such as the firmware update path which wants to lock once\n> and then unlock when finished after performing several tasks.\n> \n> Although this should have only affected X722 devices, commit\n> 96a39aed25e6 (\"i40e: Acquire NVM lock before reads on all devices\",\n> 2016-12-02) added locking for all NVM reads, regardless of device\n> family.\n> \n> This resulted in us accidentally causing NVM acquire timeouts on all\n> devices, causing failed firmware updates which left the eeprom in\n> a corrupt state.\n> \n> Create unsafe non-locked variants of i40e_read_nvm_word and\n> i40e_read_nvm_buffer, __i40e_read_nvm_word and __i40e_read_nvm_buffer\n> respectively. These variants will not take the NVM lock and are expected\n> to only be called in places where the NVM lock is already held if\n> needed.\n> \n> Since the only caller of i40e_read_nvm_buffer() was in such a path,\n> remove it entirely in favor of the unsafe version. If necessary we can\n> always add it back in the future.\n> \n> Additionally, we now need to hold the NVM lock in i40e_validate_checksum\n> because the call to i40e_calc_nvm_checksum now assumes that the NVM lock\n> is held. We can further move the call to read I40E_SR_SW_CHECKSUM_WORD\n> up a bit so that we do not need to acquire the NVM lock twice.\n> \n> This should resolve firmware updates and also fix potential raise that\n> could have caused the driver to report an invalid NVM checksum upon\n> driver load.\n> \n> Reported-by: Stefan Assmann \n> Fixes: 96a39aed25e6 (\"i40e: Acquire NVM lock before reads on all devices\", 2016-12-02)\n> Signed-off-by: Anjali Singhai Jain \n> Signed-off-by: Jacob Keller \n> ---\n> \n> This is a more complete version of the patch suggested by Stefan, found\n> at https://patchwork.ozlabs.org/patch/808699/ and it should be able to\n> avoid needing the 2nd patch in his series, which reverted a workqueue\n> change. The code is slightly refactored from what he suggested, and also\n> includes the i40e_nvm_read_buffer() function, as well as fixing up the\n> issues in i40e_validate_checksum().\n> \n> Stefan, can you let me know if this works for you? I didn't have any\n> issues, but I'd like to confirm this fix is acceptable to you.\n\nHi Jacob,\n\nI've reflashed all the NICs I had available, everything went smoothly.\nLet's get your patch in asap.\n\nThanks!\n\n Stefan","headers":{"Return-Path":"","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"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.133; helo=hemlock.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","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 3xlMBK5Tdjz9sDB\n\tfor ;\n\tSun, 3 Sep 2017 15:35:04 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 506AB820EE;\n\tSun, 3 Sep 2017 05:35:02 +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 IeDrJw9wRWlY; Sun, 3 Sep 2017 05:35:00 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 751C982115;\n\tSun, 3 Sep 2017 05:35:00 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 917421C26D0\n\tfor ;\n\tSun, 3 Sep 2017 05:34:59 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 8B4AA86E75\n\tfor ;\n\tSun, 3 Sep 2017 05:34:59 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id ejU+XTqYeGXu for ;\n\tSun, 3 Sep 2017 05:34:58 +0000 (UTC)","from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 5411986E55\n\tfor ;\n\tSun, 3 Sep 2017 05:34:57 +0000 (UTC)","from [192.168.0.11] ([91.20.115.66]) by mrelayeu.kundenserver.de\n\t(mreue002 [212.227.15.167]) with ESMTPSA (Nemesis) id\n\t0MdifM-1e9KiO34cm-00PKyY; Sun, 03 Sep 2017 07:34:44 +0200"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","To":"Jacob Keller ,\n\tIntel Wired LAN ","References":"<20170901204249.3835-1-jacob.e.keller@intel.com>","From":"Stefan Assmann ","Message-ID":"<63fe2862-d5f7-8ad5-a171-a1a3af89a1bb@kpanic.de>","Date":"Sun, 3 Sep 2017 07:34:42 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170901204249.3835-1-jacob.e.keller@intel.com>","Content-Language":"de-DE","X-Provags-ID":"V03:K0:2faEpKH1QPPaUuZY0qhrJA0+CUplFxPRartg7j0JYBM0HKksCJi\n\t3aeI6Udbo1EAOyByFBUAMGYUGQNg3BPWGEJgxBJG2Y7TDNxS4IVE0XRviactdoLYc+prvxx\n\tBg48Sp+hrtA56sPzc6dGAteRPhILQji5VdxwMhv8+/6The4ERR67MKaXvxJ9hjyBc5zS4zf\n\tAe+se+W4zVQV7ECMQIcxQ==","X-UI-Out-Filterresults":"notjunk:1; V01:K0:zEMGPt6JP9Y=:8sh1tCM+D+CKL4Ygos/ZQw\n\tQIy3HMpfGskj13Cl86nU4xTtVSatB3rmPlM2rHmGbvi9bH1gOVhdPvgmaHwtZxRKRbrIOWnC/\n\txPnW1YSH2tBztG1dzsjp7JnVJb4vwiphZHGSUkg66SAlJ8Yhxo9u+g/WX1UFN5J206aWAspSq\n\t/LAnW0ZqmgDiOf1ybPK2JVwM2kxlqUkAtjFx11wR57APXxMbSxKuJ6g+feG6DXQhd1B19iOzD\n\tVs5KcX/7CrBlJxmZ6iW0XpO5UevplnPsObTJQF/0RKOTPN76Iq/2JD2ciq7w1E0LHO+CdUaCe\n\tltZu5Nd67BonJiVsiPpMYdFyJsJom5EYurpBLy0SSy5XjmwqCjvOaUWImCMYZ7G2KUFJUlp9B\n\tOJ7pDDMBAwKqTDusMlqcmCWZAhjLY7z+qXrWHVx6SAv0oEJEg3V6izTCYhFQDghbdRkh3bcwY\n\tip8iMs6dUXydgkcBdbdffT/E98/Pazr2veRGXtEYeu5NGnF8nlQf6J1+f+/Oeoa8fe6kItIap\n\t5fyGERJdlYhg7fMh9o+bP5kvQTsaIIg88r0nallZKKwB0JEuokmnBT2PI1TgKNHHAk5EGsawr\n\tvVUxB/LO3HI6SEl5nMAyuT0qSQeUImYhl0wIzBbeKEQ/pJWak6nbo0f1jk0VMonoTwi62lHfn\n\tYzGbcOqxLLDZFmXP/mS2dnVQKl5JVK4EqWlCfh7f9KmgguUUid4TbOn63mZLngY7keLveQ6uf\n\tMqNk2phFJMBjAQbNp4rArNSCdzjMc0ofSWqQ6ZxR1lce4jeurLlBObCdAaE=","Subject":"Re: [Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock\n\tduring NVM update","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","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1763693,"web_url":"http://patchwork.ozlabs.org/comment/1763693/","msgid":"<02874ECE860811409154E81DA85FBB5882A9B0C1@ORSMSX115.amr.corp.intel.com>","list_archive_url":null,"date":"2017-09-05T22:00:27","subject":"Re: [Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock\n\tduring NVM update","submitter":{"id":9784,"url":"http://patchwork.ozlabs.org/api/people/9784/","name":"Jacob Keller","email":"jacob.e.keller@intel.com"},"content":"> -----Original Message-----\n> From: Stefan Assmann [mailto:sassmann@kpanic.de]\n> Sent: Saturday, September 02, 2017 10:35 PM\n> To: Keller, Jacob E ; Intel Wired LAN lan@lists.osuosl.org>\n> Cc: Singhai, Anjali \n> Subject: Re: [PATCH] i40e: avoid NVM acquire deadlock during NVM update\n> \n> On 01.09.2017 22:42, Jacob Keller wrote:\n> > From: Anjali Singhai Jain \n> >\n> > X722 devices use the AdminQ to access the NVM, and this requires taking\n> > the AdminQ lock. Because of this, we lock the AdminQ during\n> > i40e_read_nvm(), which is also called in places where the lock is\n> > already held, such as the firmware update path which wants to lock once\n> > and then unlock when finished after performing several tasks.\n> >\n> > Although this should have only affected X722 devices, commit\n> > 96a39aed25e6 (\"i40e: Acquire NVM lock before reads on all devices\",\n> > 2016-12-02) added locking for all NVM reads, regardless of device\n> > family.\n> >\n> > This resulted in us accidentally causing NVM acquire timeouts on all\n> > devices, causing failed firmware updates which left the eeprom in\n> > a corrupt state.\n> >\n> > Create unsafe non-locked variants of i40e_read_nvm_word and\n> > i40e_read_nvm_buffer, __i40e_read_nvm_word and __i40e_read_nvm_buffer\n> > respectively. These variants will not take the NVM lock and are expected\n> > to only be called in places where the NVM lock is already held if\n> > needed.\n> >\n> > Since the only caller of i40e_read_nvm_buffer() was in such a path,\n> > remove it entirely in favor of the unsafe version. If necessary we can\n> > always add it back in the future.\n> >\n> > Additionally, we now need to hold the NVM lock in i40e_validate_checksum\n> > because the call to i40e_calc_nvm_checksum now assumes that the NVM lock\n> > is held. We can further move the call to read I40E_SR_SW_CHECKSUM_WORD\n> > up a bit so that we do not need to acquire the NVM lock twice.\n> >\n> > This should resolve firmware updates and also fix potential raise that\n> > could have caused the driver to report an invalid NVM checksum upon\n> > driver load.\n> >\n> > Reported-by: Stefan Assmann \n> > Fixes: 96a39aed25e6 (\"i40e: Acquire NVM lock before reads on all devices\", 2016-\n> 12-02)\n> > Signed-off-by: Anjali Singhai Jain \n> > Signed-off-by: Jacob Keller \n> > ---\n> >\n> > This is a more complete version of the patch suggested by Stefan, found\n> > at https://patchwork.ozlabs.org/patch/808699/ and it should be able to\n> > avoid needing the 2nd patch in his series, which reverted a workqueue\n> > change. The code is slightly refactored from what he suggested, and also\n> > includes the i40e_nvm_read_buffer() function, as well as fixing up the\n> > issues in i40e_validate_checksum().\n> >\n> > Stefan, can you let me know if this works for you? I didn't have any\n> > issues, but I'd like to confirm this fix is acceptable to you.\n> \n> Hi Jacob,\n> \n> I've reflashed all the NICs I had available, everything went smoothly.\n> Let's get your patch in asap.\n> \n> Thanks!\n> \n> Stefan\n\nExcellent news!\n\nThanks,\nJake","headers":{"Return-Path":"","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"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.133; helo=hemlock.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","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 3xn0yd17gtz9s7h\n\tfor ;\n\tWed, 6 Sep 2017 08:00:41 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id A2B24894C5;\n\tTue, 5 Sep 2017 22:00:39 +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 RgqWUrPOrg7w; Tue, 5 Sep 2017 22:00:38 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 215528945E;\n\tTue, 5 Sep 2017 22:00:38 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 91E511C104C\n\tfor ;\n\tTue, 5 Sep 2017 22:00:36 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 85E2B30A53\n\tfor ;\n\tTue, 5 Sep 2017 22:00:36 +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 0zMtsg5hYV0A for ;\n\tTue, 5 Sep 2017 22:00:29 +0000 (UTC)","from mga06.intel.com (mga06.intel.com [134.134.136.31])\n\tby silver.osuosl.org (Postfix) with ESMTPS id C3B1525406\n\tfor ;\n\tTue, 5 Sep 2017 22:00:28 +0000 (UTC)","from orsmga004.jf.intel.com ([10.7.209.38])\n\tby orsmga104.jf.intel.com with ESMTP; 05 Sep 2017 15:00:28 -0700","from orsmsx107.amr.corp.intel.com ([10.22.240.5])\n\tby orsmga004.jf.intel.com with ESMTP; 05 Sep 2017 15:00:28 -0700","from orsmsx115.amr.corp.intel.com ([169.254.4.109]) by\n\tORSMSX107.amr.corp.intel.com ([169.254.1.76]) with mapi id\n\t14.03.0319.002; Tue, 5 Sep 2017 15:00:28 -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.41,481,1498546800\"; d=\"scan'208\";a=\"125866862\"","From":"\"Keller, Jacob E\" ","To":"Stefan Assmann , Intel Wired LAN\n\t","Thread-Topic":"[PATCH] i40e: avoid NVM acquire deadlock during NVM update","Thread-Index":"AQHTI2Ln7cnRNqpDykes6xsqVHoA+6KjG0IAgAPCqEA=","Date":"Tue, 5 Sep 2017 22:00:27 +0000","Message-ID":"<02874ECE860811409154E81DA85FBB5882A9B0C1@ORSMSX115.amr.corp.intel.com>","References":"<20170901204249.3835-1-jacob.e.keller@intel.com>\n\t<63fe2862-d5f7-8ad5-a171-a1a3af89a1bb@kpanic.de>","In-Reply-To":"<63fe2862-d5f7-8ad5-a171-a1a3af89a1bb@kpanic.de>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmM1NDEyYTctNDgyMS00OTkzLTk0ZDMtYmNhMTJhZTc3YTVjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Im1ibXRUSGVvNStGdVU0XC9mWGlsS24xXC8xVGlXa2ZNdlhyQVVHU29xdDdPVT0ifQ==","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[10.22.254.140]","MIME-Version":"1.0","Subject":"Re: [Intel-wired-lan] [PATCH] i40e: avoid NVM acquire deadlock\n\tduring NVM update","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","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}}]