lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Jan 2015 09:48:40 +0800 From: ethan zhao <ethan.zhao@...cle.com> To: "Dev, Vasu" <vasu.dev@...el.com> CC: Ethan Zhao <ethan.kernel@...il.com>, "Ronciak, John" <john.ronciak@...el.com>, "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>, "Brandeburg, Jesse" <jesse.brandeburg@...el.com>, "Allan, Bruce W" <bruce.w.allan@...el.com>, "Wyborny, Carolyn" <carolyn.wyborny@...el.com>, "Skidmore, Donald C" <donald.c.skidmore@...el.com>, "Rose, Gregory V" <gregory.v.rose@...el.com>, "Vick, Matthew" <matthew.vick@...el.com>, "Williams, Mitch A" <mitch.a.williams@...el.com>, "Parikh, Neerav" <neerav.parikh@...el.com>, Linux NICS <Linux-nics@...tope.jf.intel.com>, "e1000-devel@...ts.sourceforge.net" <e1000-devel@...ts.sourceforge.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "brian.maly@...cle.com" <brian.maly@...cle.com> Subject: Re: [PATCH] i40e: don't enable and init FCOE by default when do PF reset Vasu, OK, disable FCOE as default configuration as a temporary step to make it work. Thanks, Ethan On 2015/1/16 7:45, Dev, Vasu wrote: >> -----Original Message----- >> From: ethan zhao [mailto:ethan.zhao@...cle.com] >> Sent: Tuesday, January 13, 2015 6:41 PM >> To: Dev, Vasu >> Cc: Ethan Zhao; Ronciak, John; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, >> Bruce W; Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Vick, >> Matthew; Williams, Mitch A; Parikh, Neerav; Linux NICS; e1000- >> devel@...ts.sourceforge.net; netdev@...r.kernel.org; linux- >> kernel@...r.kernel.org; brian.maly@...cle.com >> Subject: Re: [PATCH] i40e: don't enable and init FCOE by default when do PF >> reset >> >> Vasu, >> >> On 2015/1/14 3:38, Dev, Vasu wrote: >>>> -----Original Message----- >>>>>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c >>>>>>> b/drivers/net/ethernet/intel/i40e/i40e_main.c >>>>>>> index a5f2660..a2572cc 100644 >>>>>>> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c >>>>>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c >>>>>>> @@ -6180,9 +6180,12 @@ static void i40e_reset_and_rebuild(struct >>>>>>> i40e_pf *pf, bool reinit) >>>>>>> } >>>>>>> #endif /* CONFIG_I40E_DCB */ >>>>>>> #ifdef I40E_FCOE >>>>>>> - ret = i40e_init_pf_fcoe(pf); >>>>>>> - if (ret) >>>>>>> - dev_info(&pf->pdev->dev, "init_pf_fcoe failed: %d\n", ret); >>>>>>> + if (pf->flags & I40E_FLAG_FCOE_ENABLED) { >>>>>>> + ret = i40e_init_pf_fcoe(pf); >>>>> Calling i40e_init_pf_fcoe() here conflicts with its >>>> I40E_FLAG_FCOE_ENABLED pre-condition since >> I40E_FLAG_FCOE_ENABLED is >>>> set by very same i40e_init_pf_fcoe(), in turn i40e_init_pf_fcoe() >>>> will never get called. >>>> >>>> I don't think so, here ,i40e_reset_and_rebuild() is not the only >>>> and the first place that i40e_init_pf_fcoe() is called, see >>>> i40e_probe(), that is the first chance. >>>> >>>> i40e_probe() >>>> -->i40e_sw_init() >>>> -->i40e_init_pf_fcoe() >>>> >>>> And the I40E_FLAG_FCOE_ENABLED is possible be set by >>>> i40e_fcoe_enable() or i40e_fcoe_disable() interface before the reset >>>> action is to be done. >>>> >>> It is set by i40e_init_pf_fcoe() and you are right that the modified call flow >> by your patch won't impact setting of I40E_FLAG_FCOE_ENABLED anyway >> which could have prevented calling i40e_init_pf_fcoe() as I described above, >> so this is not an issue with the patch. >>>> BTW, the reason I post this patch is that we hit a bug, after setup >>>> vlan, the PF is enabled to FCOE. >>>> >>> Then that BUG would still remain un-fixed and calling i40e_init_pf_fcoe() >> under I40E_FLAG_FCOE_ENABLED flag really won't affect call flow to fix >> anything. I mean I40E_FLAG_FCOE_ENABLED condition will be true with "pf- >>> hw.func_caps.fcoe == true" and otherwise calling i40e_init_pf_fcoe() simply >> returns back early on after checking "pf->hw.func_caps.fcoe == false", so >> how that bug is fixed here by added I40E_FLAG_FCOE_ENABLED condition ? >> What is the bug ? >> The func_caps.fcoe is assigned by following call path, under our test >> environment, >> >> i40e_probe() >> ->i40e_get_capabilities() >> ->i40e_aq_discover_capabilities() >> ->i40e_parse_discover_capabilities() >> >> Or >> >> i40e_reset_and_rebuild() >> ->i40e_get_capabilities() >> ->i40e_aq_discover_capabilities() >> ->i40e_parse_discover_capabilities() >> >> Under our test environment, the "pf->hw.func_caps.fcoe" is true. so if >> i40e_reset_and_rebuild() is called for VLAN setup, ethtool diagnostic test. >> And then i40e_init_pf_fcoe() is to be called, >> >> While if (!pf->hw.func_caps.fcoe) wouldn't return, >> > I said it would return with "pf->hw.func_caps.fcoe == false" in my last response, more details below. > >> So pf->flags is set to I40E_FLAG_FCOE_ENABLED. >> >> With my patch, i40e_init_pf_fcoe() is only called after >> I40E_FLAG_FCOE_ENABLED is set before reset. >> >> Enable FCOE in i40e_probe() or not is another issue. >> > Nope since both cases we should do i40e_init_pf_fcoe() or don't based on fcoe cap true or false. > > I don't have much to add as I described before with the your patch that "calling i40e_init_pf_fcoe() under I40E_FLAG_FCOE_ENABLED flag really won't affect call flow to fix anything. I mean I40E_FLAG_FCOE_ENABLED condition will be true with "pf->hw.func_caps.fcoe == true" and otherwise calling i40e_init_pf_fcoe() simply returns back early on after checking "pf->hw.func_caps.fcoe == false". > > May be I'm missing something, I guess next either go with CONFIG_I40E_FCOE disable as I suggested before and now it in upstream kernel or we can have further off list discussion to fix the issue you are trying to fix with the patch. > > Thanks, > Vasu > >> Thanks, >> Ethan >> >> >>>>> Jeff Kirsher should be getting out a patch queued by me which adds >>>> I40E_FCoE Kbuild option, in that FCoE is disabled by default and >>>> user could enable FCoE only if needed, that patch would do same of >>>> skipping >>>> i40e_init_pf_fcoe() whether FCoE capability in device enabled or not >>>> in default config. >>>> The following patch will not fix the above issue -- configuration of >>>> PF will be changed via reset. >>>> How about the FCOE is configured and disabled by i40e_fcoe_disable() >>>> , then reset happens ? >>>> >>> May be but if the BUG is due to FCoE being enabled then having it disabled >> in config will avoid the bug for non FCoE config option and once bug is >> understood then that has to be fixed for FCoE enabled config also as I asked >> above. >>> Thanks Ethan for detailed response. >>> Vasu >>> >>>>> From patchwork Wed Oct 2 23:26:08 2013 >>>>> Content-Type: text/plain; charset="utf-8" >>>>> MIME-Version: 1.0 >>>>> Content-Transfer-Encoding: 7bit >>>>> Subject: [net] i40e: adds FCoE configure option >>>>> Date: Thu, 03 Oct 2013 07:26:08 -0000 >>>>> From: Vasu Dev <vasu.dev@...el.com> >>>>> X-Patchwork-Id: 11797 >>>>> >>>>> Adds FCoE config option I40E_FCOE, so that FCoE can be enabled as >>>>> needed but otherwise have it disabled by default. >>>>> >>>>> This also eliminate multiple FCoE config checks, instead now just >>>>> one config check for CONFIG_I40E_FCOE. >>>>> >>>>> The I40E FCoE was added with 3.17 kernel and therefore this patch >>>>> shall be applied to stable 3.17 kernel also. >>>>> >>>>> CC: <stable@...r.kernel.org> >>>>> Signed-off-by: Vasu Dev <vasu.dev@...el.com> >>>>> Tested-by: Jim Young <jamesx.m.young@...el.com> >>>>> >>>>> --- >>>>> drivers/net/ethernet/intel/Kconfig | 11 +++++++++++ >>>>> drivers/net/ethernet/intel/i40e/Makefile | 2 +- >>>>> drivers/net/ethernet/intel/i40e/i40e_osdep.h | 4 ++-- >>>>> 3 files changed, 14 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/net/ethernet/intel/Kconfig >>>>> b/drivers/net/ethernet/intel/Kconfig >>>>> index 5b8300a..4d61ef5 100644 >>>>> --- a/drivers/net/ethernet/intel/Kconfig >>>>> +++ b/drivers/net/ethernet/intel/Kconfig >>>>> @@ -281,6 +281,17 @@ config I40E_DCB >>>>> >>>>> If unsure, say N. >>>>> >>>>> +config I40E_FCOE >>>>> + bool "Fibre Channel over Ethernet (FCoE)" >>>>> + default n >>>>> + depends on I40E && DCB && FCOE >>>>> + ---help--- >>>>> + Say Y here if you want to use Fibre Channel over Ethernet (FCoE) >>>>> + in the driver. This will create new netdev for exclusive FCoE >>>>> + use with XL710 FCoE offloads enabled. >>>>> + >>>>> + If unsure, say N. >>>>> + >>>>> config I40EVF >>>>> tristate "Intel(R) XL710 X710 Virtual Function Ethernet support" >>>>> depends on PCI_MSI >>>>> diff --git a/drivers/net/ethernet/intel/i40e/Makefile >>>>> b/drivers/net/ethernet/intel/i40e/Makefile >>>>> index 4b94ddb..c405819 100644 >>>>> --- a/drivers/net/ethernet/intel/i40e/Makefile >>>>> +++ b/drivers/net/ethernet/intel/i40e/Makefile >>>>> @@ -44,4 +44,4 @@ i40e-objs := i40e_main.o \ >>>>> i40e_virtchnl_pf.o >>>>> >>>>> i40e-$(CONFIG_I40E_DCB) += i40e_dcb.o i40e_dcb_nl.o >>>>> -i40e-$(CONFIG_FCOE:m=y) += i40e_fcoe.o >>>>> +i40e-$(CONFIG_I40E_FCOE) += i40e_fcoe.o >>>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_osdep.h >>>>> b/drivers/net/ethernet/intel/i40e/i40e_osdep.h >>>>> index 045b5c4..ad802dd 100644 >>>>> --- a/drivers/net/ethernet/intel/i40e/i40e_osdep.h >>>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_osdep.h >>>>> @@ -78,7 +78,7 @@ do { \ >>>>> } while (0) >>>>> >>>>> typedef enum i40e_status_code i40e_status; -#if >>>>> defined(CONFIG_FCOE) >>>>> || defined(CONFIG_FCOE_MODULE) >>>>> +#ifdef CONFIG_I40E_FCOE >>>>> #define I40E_FCOE >>>>> -#endif /* CONFIG_FCOE or CONFIG_FCOE_MODULE */ >>>>> +#endif >>>>> #endif /* _I40E_OSDEP_H_ */ >>>>> >>>>>>> + if (ret) >>>>>>> + dev_info(&pf->pdev->dev, >>>>>>> + "init_pf_fcoe failed: %d\n", ret); >>>>>>> + } >>>>>>> >>>>>>> #endif >>>>>>> /* do basic switch setup */ >>>>>>> -- >>>>>>> 1.8.3.1 >>>> Thanks, >>>> Ethan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists