* Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
From: Ding Tianhong @ 2015-01-20 2:15 UTC (permalink / raw)
To: Arnd Bergmann, Alexander Graf
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-lFZ/pmaqli7XmaaqVzeoHQ
In-Reply-To: <9314032.C8yR0htxiP@wuerfel>
On 2015/1/20 4:34, Arnd Bergmann wrote:
> On Monday 19 January 2015 19:11:11 Alexander Graf wrote:
>>
>> After hammering on the box a bit again, I'm in a situation where I get
>> lots of
>>
>> [302398.232603] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302398.377309] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302398.395198] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302398.466118] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302398.659009] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302399.053389] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302399.122067] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302399.268192] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302399.286081] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302399.594201] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302399.683416] hip04-ether e28b0000.ethernet eth0: rx drop
>> [302399.701307] hip04-ether e28b0000.ethernet eth0: rx drop
>>
>> and I really am getting a lot of drops - I can't even ping the machine
>> anymore.
>>
>> However, as it is there's a good chance the machine is simply
>> unreachable because it's busy writing to the UART, and even if not all
>> useful messages indicating anything have scrolled out. I really don't
>> think you should emit any message over and over again to the user. Once
>> or twice is enough.
>>
>> Please make sure to rate limit it.
>
> I would argue that packet loss is not an error condition at all
> and you should not print this at netdev_err() level. You could make
> this a netdev_dbg(), or just make it silent because it's already
> counted in the statistics.
>
I think something wrong with Graf's board, I will try to make it happen on my board, and
in any case I will add rate limit to xx_drop and change to dbg log level.
Thanks
Ding
> Arnd
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] i40e: don't enable and init FCOE by default when do PF reset
From: ethan zhao @ 2015-01-20 2:05 UTC (permalink / raw)
To: Dev, Vasu
Cc: e1000-devel@lists.sourceforge.net, brian.maly@oracle.com,
Allan, Bruce W, Brandeburg, Jesse, Parikh, Neerav, Linux NICS,
Ronciak, John, netdev@vger.kernel.org, Ethan Zhao,
linux-kernel@vger.kernel.org
In-Reply-To: <933BEC2E04D6A5458F4B0239FB547F9A34CCE42B@fmsmsx118.amr.corp.intel.com>
On 2015/1/20 5:10, Dev, Vasu wrote:
>> -----Original Message-----
>> From: ethan zhao [mailto:ethan.zhao@oracle.com]
>> Sent: Friday, January 16, 2015 7:01 PM
>> To: Kirsher, Jeffrey T
>> Cc: Dev, Vasu; Ethan Zhao; Ronciak, John; Brandeburg, Jesse; Allan, Bruce W;
>> Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Vick, Matthew;
>> Williams, Mitch A; Parikh, Neerav; Linux NICS; e1000-
>> devel@lists.sourceforge.net; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org; brian.maly@oracle.com
>> Subject: Re: [PATCH] i40e: don't enable and init FCOE by default when do PF
>> reset
>>
>> Vasu,
>>
>> What' your idea about the v2, any suggestion ? Jeff is looking forward to
>> see it.
>>
> Jeff was asking for v2 in response to your last comment as "disable FCOE as default configuration as a temporary step" but I think that is the fix and user should n't enable FCoE until they have FCoE enabled X710 FCoE with either fabric or VN2VN mode FCoE setup.
As a Linux distro, we don't know users have FCoE capable X710 or not,
so we couldn't disable the FCoE configuration
by default in the released kernel except FCoE is officially not
supported yet with X710, but if yes, fix those bugs I
mentioned is the only choice.
Thanks,
Ethan
>
> Thanks,
> Vasu
>
>> Thanks,
>> Ethan
>>
>>
>> On 2015/1/16 22:47, Jeff Kirsher wrote:
>>> On Fri, 2015-01-16 at 09:48 +0800, ethan zhao wrote:
>>>> Vasu,
>>>>
>>>> OK, disable FCOE as default configuration as a temporary step to
>>>> make it work.
>>> Sounds like I should expect a v2 coming, correct?
>>>
>>>> Thanks,
>>>> Ethan
>>>>
>>>> On 2015/1/16 7:45, Dev, Vasu wrote:
>>>>>> -----Original Message-----
>>>>>> From: ethan zhao [mailto:ethan.zhao@oracle.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@lists.sourceforge.net; netdev@vger.kernel.org;
>>>>>> linux- kernel@vger.kernel.org; brian.maly@oracle.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@intel.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@vger.kernel.org>
>>>>>>>>> Signed-off-by: Vasu Dev <vasu.dev@intel.com>
>>>>>>>>> Tested-by: Jim Young <jamesx.m.young@intel.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
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2015-01-20 1:07 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Socket addresses returned in the error queue need to be fully
initialized before being passed on to userspace, fix from
Willem de Bruijn.
2) Interrupt handling fixes to davinci_emac driver from Tony
Lindgren.
3) Fix races between receive packet steering and cpu hotplug, from
Eric Dumazet.
4) Allowing netlink sockets to subscribe to unknown multicast groups
leads to crashes, don't allow it. From Johannes Berg.
5) One to many socket races in SCTP fixed by Daniel Borkmann.
6) Put in a guard against the mis-use of ipv6 atomic fragments, from
Hagen Paul Pfeifer.
7) Fix promisc mode and ethtool crashes in sh_eth driver, from Ben
Hutchings.
8) Null deref and double kfree fix in sxgbe driver from Girish K.S
and Byungho An.
9) cfg80211 deadlock fix from Arik Nemtsov.
Please pull, thanks a lot!
The following changes since commit a6391a924cf5a16761ccd6b45094a7d5b9aeebac:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-01-15 11:17:37 +1300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to a8c1d28ac3925b99b5a939617d3fef1644298ee8:
s2io: use snprintf() as a safety feature (2015-01-19 19:42:21 -0500)
----------------------------------------------------------------
Ahmed S. Darwish (4):
can: kvaser_usb: Don't free packets when tight on URBs
can: kvaser_usb: Reset all URB tx contexts upon channel close
can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels
can: kvaser_usb: Don't dereference skb after a netif_rx()
Arik Nemtsov (1):
cfg80211: fix deadlock during reg chan check
Ben Hutchings (2):
sh_eth: Fix promiscuous mode on chips without TSU
sh_eth: Fix ethtool operation crash when net device is down
Byungho An (1):
net: sxgbe: Fix waring for double kfree()
Dan Carpenter (1):
s2io: use snprintf() as a safety feature
Daniel Borkmann (1):
net: sctp: fix race for one-to-many sockets in sendmsg's auto associate
David S. Miller (6):
Merge tag 'mac80211-for-davem-2015-01-15' of git://git.kernel.org/.../jberg/mac80211
Merge tag 'linux-can-fixes-for-3.19-20150115' of git://git.kernel.org/.../mkl/linux-can
Merge branch 'davinci_emac'
Merge branch 'sh_eth'
Merge branch 'bgmac'
Merge branch 'r8152'
Eric Dumazet (1):
net: rps: fix cpu unplug
Geert Uytterhoeven (1):
sh_eth: Fix addition of .trscer_err_mask to wrong SoC data
Girish K.S (1):
net: sxgbe: Fix NULL dereferece when using DT
Hagen Paul Pfeifer (1):
ipv6: stop sending PTB packets for MTU < 1280
Hauke Mehrtens (2):
bgmac: register napi before the device
bgmac: activate irqs only if there is nothing to poll
Johannes Berg (3):
genetlink: document parallel_ops
genetlink: disallow subscribing to unknown mcast groups
genetlink: synchronize socket closing and family removal
John Linville (1):
mac80211: uninitialized return val in __ieee80211_sta_handle_tspec_ac_params
Marc Kleine-Budde (1):
MAINTAINERS: update linux-can git repositories
Mugunthan V N (1):
drivers: net: cpsw: fix cpsw hung with add vlan using vconfig
Oliver Hartkopp (2):
can: dev: fix crtlmode_supported check
can: m_can: tag current CAN FD controllers as non-ISO
Or Gerlitz (1):
net/mlx4: Don't disable vxlan offloads under DMFS-A0 optimized steering
Roger Quadros (1):
can: c_can: use regmap_update_bits() to modify RAMINIT register
Sriharsha Basavapatna (1):
be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
Tony Lindgren (6):
net: davinci_emac: Fix hangs with interrupts
net: davinci_emac: Fix runtime pm calls for davinci_emac
net: davinci_emac: Free clock after checking the frequency
net: davinci_emac: Fix incomplete code for getting the phy from device tree
net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC address space
net: davinci_emac: Add support for emac on dm816x
Willem de Bruijn (1):
ip: zero sockaddr returned on error queue
hayeswang (2):
r8152: remove generic_ocp_read before writing
r8152: remove sram_read
Documentation/devicetree/bindings/net/davinci_emac.txt | 3 +-
MAINTAINERS | 6 ++--
drivers/infiniband/hw/mlx4/main.c | 3 +-
drivers/net/can/c_can/c_can_platform.c | 29 ++++++++++-------
drivers/net/can/dev.c | 8 +++--
drivers/net/can/m_can/m_can.c | 5 +++
drivers/net/can/usb/kvaser_usb.c | 31 +++++++++---------
drivers/net/ethernet/broadcom/bgmac.c | 12 +++----
drivers/net/ethernet/emulex/benet/be_main.c | 41 +++++++++++++++++++++--
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 3 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 3 +-
drivers/net/ethernet/neterion/s2io.c | 11 +++++--
drivers/net/ethernet/renesas/sh_eth.c | 32 +++++++++++-------
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 21 ++++++------
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c | 8 ++---
drivers/net/ethernet/ti/cpsw.c | 27 +++++++++------
drivers/net/ethernet/ti/davinci_emac.c | 96 ++++++++++++++++++++++++++++++++++++++++++------------
drivers/net/usb/r8152.c | 30 ++++-------------
include/linux/genetlink.h | 4 +++
include/net/genetlink.h | 7 +++-
include/uapi/linux/can/netlink.h | 1 +
net/core/dev.c | 20 +++++++++---
net/ipv4/ip_sockglue.c | 8 ++---
net/ipv6/datagram.c | 10 ++----
net/ipv6/route.c | 7 ++--
net/mac80211/mlme.c | 2 +-
net/netlink/af_netlink.c | 24 ++++++++++----
net/netlink/af_netlink.h | 1 +
net/netlink/genetlink.c | 18 +++++-----
net/sctp/socket.c | 8 ++++-
net/wireless/reg.c | 56 ++++++++++++++++++-------------
31 files changed, 343 insertions(+), 192 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] tipc: ratelimit network event traces
From: David Miller @ 2015-01-20 0:46 UTC (permalink / raw)
To: erik.hugne; +Cc: richard.alpe, ying.xue, jon.maloy, netdev, tipc-discussion
In-Reply-To: <1421658164-26185-1-git-send-email-erik.hugne@ericsson.com>
From: <erik.hugne@ericsson.com>
Date: Mon, 19 Jan 2015 10:02:44 +0100
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> If a large number of namespaces is spawned on a node and TIPC is
> enabled in each of these, the excessive printk tracing of network
> events will cause the system to grind down to a near halt.
> We fix this by adding ratelimiting to the info/warning logs
> regarding link state and node availability.
>
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Reviewed-by: Ying Xue <ying.xue@windriver.com>
Really these various state transition messages that are enabled
by default really should not be.
If you want to watch for every event like this, listen on a
netlink socket or set some debugging level param to some non-
default value.
^ permalink raw reply
* Re: [patch] s2io: use snprintf() as a safety feature
From: David Miller @ 2015-01-20 0:45 UTC (permalink / raw)
To: dan.carpenter; +Cc: jdmason, netdev, kernel-janitors
In-Reply-To: <20150119193451.GB32634@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 19 Jan 2015 22:34:51 +0300
> "sp->desc[i]" has 25 characters. "dev->name" has 15 characters. If we
> used all 15 characters then the sprintf() would overflow.
>
> I changed the "sprintf(sp->name, "%s Neterion %s"" to snprintf(), as
> well, even though it can't overflow just to be consistent.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: David Miller @ 2015-01-20 0:29 UTC (permalink / raw)
To: harouth; +Cc: dborkman, netdev
In-Reply-To: <001501d03439$28f6d670$7ae48350$@codeaurora.org>
From: "Harout Hedeshian" <harouth@codeaurora.org>
Date: Mon, 19 Jan 2015 15:42:08 -0700
> Indeed, the patch is based on previous modifications to add sysctl/proc
> entries for IPv6 parameters. It is done this way to maintain consistency. Do
> you think we need a v3 without the changes to the sysctl_binary.c and
> corresponding changes in includes/uapi?
Probably, yes.
^ permalink raw reply
* Payment
From: Finance Department @ 2015-01-19 23:11 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Daniel Borkmann @ 2015-01-19 23:01 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <001501d03439$28f6d670$7ae48350$@codeaurora.org>
On 01/19/2015 11:42 PM, Harout Hedeshian wrote:
...
> Indeed, the patch is based on previous modifications to add sysctl/proc
> entries for IPv6 parameters. It is done this way to maintain consistency. Do
> you think we need a v3 without the changes to the sysctl_binary.c and
> corresponding changes in includes/uapi?
Yep, please.
> d9333196572 ("ipv6: Allow accepting RA from local IP addresses.") is as
> recent as June 2014.
Yeah, that looks wrong unfortunately.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Daniel Borkmann @ 2015-01-19 23:01 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <1421703363-3376-1-git-send-email-harouth@codeaurora.org>
On 01/19/2015 10:36 PM, Harout Hedeshian wrote:
...
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index 85b0221..da50faa 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1287,6 +1287,13 @@ accept_ra_rtr_pref - BOOLEAN
> Functional default: enabled if accept_ra is enabled.
> disabled if accept_ra is disabled.
>
> +accept_ra_mtu - BOOLEAN
> + Apply the MTU value specified in RA option 5 (RFC4861). If
> + disabled, the MTU specified in the RA will be ignored.
> +
> + Functional default: enabled if accept_ra is enabled.
> + disabled if accept_ra is disabled.
Nit: please indent correctly with tab here.
> +
...
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index 73cb02d..437a6a4 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -169,6 +169,7 @@ enum {
> DEVCONF_SUPPRESS_FRAG_NDISC,
> DEVCONF_ACCEPT_RA_FROM_LOCAL,
> DEVCONF_USE_OPTIMISTIC,
> + DEVCONF_ACCEPT_RA_MTU,
> DEVCONF_MAX
> };
You also need a corresponding ipv6_store_devconf() entry, otherwise
netlink dumps will always see this setting as disabled.
^ permalink raw reply
* RE: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-19 22:42 UTC (permalink / raw)
To: 'Daniel Borkmann'; +Cc: netdev
In-Reply-To: <54BD80D6.40402@redhat.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Daniel Borkmann
> Sent: Monday, January 19, 2015 3:11 PM
> To: Harout Hedeshian
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable
MTU
> updates from RA
>
> On 01/19/2015 10:36 PM, Harout Hedeshian wrote:
> ...
> > diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> > index 0956373..45e4fcf 100644
> > --- a/include/uapi/linux/sysctl.h
> > +++ b/include/uapi/linux/sysctl.h
> > @@ -570,6 +570,7 @@ enum {
> > NET_IPV6_PROXY_NDP=23,
> > NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> > NET_IPV6_ACCEPT_RA_FROM_LOCAL=26,
> > + NET_IPV6_ACCEPT_RA_MTU=27,
> > __NET_IPV6_MAX
> > };
> >
> > diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c index
> > 7e7746a..16091e5 100644
> > --- a/kernel/sysctl_binary.c
> > +++ b/kernel/sysctl_binary.c
> > @@ -523,6 +523,7 @@ static const struct bin_table
> bin_net_ipv6_conf_var_table[] = {
> > { CTL_INT, NET_IPV6_PROXY_NDP,
> "proxy_ndp" },
> > { CTL_INT, NET_IPV6_ACCEPT_SOURCE_ROUTE,
> "accept_source_route" },
> > { CTL_INT, NET_IPV6_ACCEPT_RA_FROM_LOCAL,
> "accept_ra_from_local" },
> > + { CTL_INT, NET_IPV6_ACCEPT_RA_MTU,
> "accept_ra_mtu" },
> > {}
> > };
>
> Hm, afaik, the binary sysctl interface is deprecated and nothing should be
> adding entries there anymore. I believe you copied this over from commit
> d9333196572 ("ipv6: Allow accepting RA from local IP addresses.")? :/
Hi Daniel,
Indeed, the patch is based on previous modifications to add sysctl/proc
entries for IPv6 parameters. It is done this way to maintain consistency. Do
you think we need a v3 without the changes to the sysctl_binary.c and
corresponding changes in includes/uapi?
d9333196572 ("ipv6: Allow accepting RA from local IP addresses.") is as
recent as June 2014.
Thanks,
Harout
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
^ permalink raw reply
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Herbert Xu @ 2015-01-19 22:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Jarosch, netdev, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <CANn89iLpgUEuHQvyJHR8g3q62-Hi-XfYKeVpLvG__UQLrqR5Bg@mail.gmail.com>
On Mon, Jan 19, 2015 at 02:38:47PM -0800, Eric Dumazet wrote:
>
> SYN and FIN packets are in the send queue.
>
> They are valid and might have a zero size.
Right, obviously I meant packets in between the SYN and the FIN.
Technically SYN/FIN are not really zero-sided since they carry
one bit of information and yes they do get cleaned while the ones
in the middle will not.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Eric Dumazet @ 2015-01-19 22:38 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Jarosch, netdev, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <20150119223635.GA8735@gondor.apana.org.au>
On Mon, Jan 19, 2015 at 2:36 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Jan 19, 2015 at 09:19:48AM -0800, Eric Dumazet wrote:
>> Zero sized packets are valid, just take a look at tcpdump ;)
>
> But zero-sized packets in the send queue are not valid and will
> not ever be cleaned, which is what triggered the original bug.
SYN and FIN packets are in the send queue.
They are valid and might have a zero size.
^ permalink raw reply
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Herbert Xu @ 2015-01-19 22:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Jarosch, netdev, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <CANn89i+U-PFbuUrp08s3Ec8BmjPFq1zj8Aj2=vPVO4-iiLkTuw@mail.gmail.com>
On Mon, Jan 19, 2015 at 09:19:48AM -0800, Eric Dumazet wrote:
> Zero sized packets are valid, just take a look at tcpdump ;)
But zero-sized packets in the send queue are not valid and will
not ever be cleaned, which is what triggered the original bug.
Although I'm not sure whether a WARN_ON will actually help since
it won't tell you why there is a zero-sized packet on the queue,
just the fact that there is. You'll know you've got a zero-sized
packet on the queue anyway by looking at the tcpdump.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Daniel Borkmann @ 2015-01-19 22:10 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <1421703363-3376-1-git-send-email-harouth@codeaurora.org>
On 01/19/2015 10:36 PM, Harout Hedeshian wrote:
...
> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> index 0956373..45e4fcf 100644
> --- a/include/uapi/linux/sysctl.h
> +++ b/include/uapi/linux/sysctl.h
> @@ -570,6 +570,7 @@ enum {
> NET_IPV6_PROXY_NDP=23,
> NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> NET_IPV6_ACCEPT_RA_FROM_LOCAL=26,
> + NET_IPV6_ACCEPT_RA_MTU=27,
> __NET_IPV6_MAX
> };
>
> diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
> index 7e7746a..16091e5 100644
> --- a/kernel/sysctl_binary.c
> +++ b/kernel/sysctl_binary.c
> @@ -523,6 +523,7 @@ static const struct bin_table bin_net_ipv6_conf_var_table[] = {
> { CTL_INT, NET_IPV6_PROXY_NDP, "proxy_ndp" },
> { CTL_INT, NET_IPV6_ACCEPT_SOURCE_ROUTE, "accept_source_route" },
> { CTL_INT, NET_IPV6_ACCEPT_RA_FROM_LOCAL, "accept_ra_from_local" },
> + { CTL_INT, NET_IPV6_ACCEPT_RA_MTU, "accept_ra_mtu" },
> {}
> };
Hm, afaik, the binary sysctl interface is deprecated and nothing
should be adding entries there anymore. I believe you copied this
over from commit d9333196572 ("ipv6: Allow accepting RA from local
IP addresses.")? :/
^ permalink raw reply
* Re: [PATCH net] ipv6: stop sending PTB packets for MTU < 1280
From: Hagen Paul Pfeifer @ 2015-01-19 22:05 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: David Miller, netdev, stable, Fernando Gont
In-Reply-To: <1421697951.13047.9.camel@stressinduktion.org>
On 19 January 2015 at 21:05, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Oh yes, although we never exposed an ip route knob for that, it is still
> possible users did set manually, so we cannot get rid of that, agreed.
I thought about that, sure but come to the conclusion that the code
cleanup outweigh an potential user somewhere in space (well, the use
case is broken and should be fixed). Additionally, I left the
RTAX_FEATURE_ALLFRAG (as mentioned) and removed all related
functionality - no visible API change (except no-op behavior).
Davem, I will sent the patch anyway. Feel free to accept/ignore.
Hagen
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: wstephen-sgV2jX0FEOL9JmXXK+q4OQ @ 2015-01-19 21:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: wstephen-sgV2jX0FEOL9JmXXK+q4OQ, jcliburn-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2318041.V2OJAPu7gC@wuerfel>
> On Thursday 15 January 2015 08:12:51 wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org wrote:
>>
>> The nss-gmac driver is for the internal GMAC IP in the Qualcomm IPQ806x
>> SoC. There are 2 ARM cores and 2 NSS cores inside the IPQ806x SoC. The
>> main purpose of these NSS cores is to offload the networking stack from
>> the ARM cores to achieve high performance at routing/ipsec..etc without
>> exhausting the ARM core CPU cycles. There is another nss-drv driver for
>> the NSS cores.
>
> I see.
>
>> The nss-gmac driver is designed to work standalone or with the nss-drv
>> driver so the switchable data plane overlay was implemented. When it
>> worked standalone, the data plane is running on the ARM core as a
>> standard
>> networking driver.
>
> How do you decide which way it gets used on a particular system?
>
By default the GMAC driver uses a native (Host ARM CPU) based data plane.
If the configuration loads the offload nss-drv driver, the offload driver
registers an overlay with the GMAC.
>> The nss-drv driver can take over the data plane and
>> offload it to the NSS cores. The STMicro stmmac driver does not have
>> this
>> kind of overlay design so is not suitable for IPQ806x. This is why we
>> don't based on the stmmac driver
>
> Which kind of offload is implemented specifically? 'data plane' sounds
> fairly generic and could mean anything, and the code isn't readable enough
> in its current form for me to find out.
The Network Subsystem (NSS core) provides a GMAC pass-through until it is
given a rule to offload work. Once a rule is given, it is capable of
performing: bridging, IPv4 NAT/FWD, IPv6 NAT/FWD, IPSec, LAG, and other
protocols.
>
> Arnd
>
Hope this clarify your question!
Thanks,
Stephen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] net: af_packet support for direct ring access in user space
From: Neil Horman @ 2015-01-19 21:45 UTC (permalink / raw)
To: David Miller
Cc: john.fastabend, netdev, danny.zhou, dborkman, john.ronciak,
hannes, brouer
In-Reply-To: <20150114.153509.1264618607573705890.davem@davemloft.net>
On Wed, Jan 14, 2015 at 03:35:09PM -0500, David Miller wrote:
> From: John Fastabend <john.fastabend@gmail.com>
> Date: Mon, 12 Jan 2015 20:35:11 -0800
>
> > + if ((region.direction != DMA_BIDIRECTIONAL) &&
> > + (region.direction != DMA_TO_DEVICE) &&
> > + (region.direction != DMA_FROM_DEVICE))
> > + return -EFAULT;
> ...
> > + if ((umem->nmap == npages) &&
> > + (0 != dma_map_sg(dev->dev.parent, umem->sglist,
> > + umem->nmap, region.direction))) {
> > + region.iova = sg_dma_address(umem->sglist) + offset;
>
> I am having trouble seeing how this can work.
>
> dma_map_{single,sg}() mappings need synchronization after a DMA
> transfer takes place.
>
> For example if the DMA occurs to the device, then that region can
> be cached in the PCI controller's internal caches and thus future
> cpu writes into that memory region will not be seen, until a
> dma_sync_*() is invoked.
>
> That isn't going to happen when the device transmit queue is
> being completely managed in userspace.
>
> And this takes us back to the issue of protection, I don't think
> it is addressed properly yet.
>
> CAP_NET_ADMIN privileges do not mean "can crap all over memory"
> yet with this feature that can still happen.
>
> If we are dealing with a device which cannot provide strict protection
> to only the process's locked local pages, you have to do something
> to implement that protection.
>
> And you have _exactly_ one option to do that, abstracting the page
> addresses and eating a system call to trigger the sends, so that you
> can read from the user's (fake) descriptors and write into the real
> descriptors (translating the DMA addresses along the way) and
> triggering the TX doorbell.
>
> I am not going to consider seriously an implementation that says "yeah
> sometimes the user can crap onto other people's memory", this isn't
> MS-DOS, it's a system where proper memory protections are mandatory
> rather than optional.
>
Another stupid question - If we can't provide protection from the device to
ensure memory coherency, can we mitigate the problem by creating an iommu group
for the device?
I'd mentioned to john the possibility of using the existing dfwd offload
operations to do the allocation of queues so that we could reuse that code instead
of having to create a set of new queue allocation routines. What if, instead of
the dfwd queue allocation methods, we used sriov functionality here? I.e.,
plumb a virtual function, and set it in its own iommu group, but instead of
passing it off to a guest, we just let the host use it? That gives us the
opportunity to tear down the iommu mappings should the process exit, so if the
physical pages get re-allocated while DMA is in flight, we can just take the
iommu exception and avoid the memory corruption.
Its not perfect, in that we're still not syncing when we should be, but I think
it would be safe at least.
Thoughts?
Neil
^ permalink raw reply
* [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-19 21:36 UTC (permalink / raw)
To: netdev; +Cc: Harout Hedeshian
The kernel forcefully applies MTU values received in router
advertisements provided the new MTU is less than the current. This
behavior is undesirable when the user space is managing the MTU. Instead
a sysctl flag 'accept_ra_mtu' is introduced such that the user space
can control whether or not RA provided MTU updates should be applied. The
default behavior is unchanged; user space must explicitly set this flag
to 0 for RA MTUs to be ignored.
Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
---
Documentation/networking/ip-sysctl.txt | 7 +++++++
include/linux/ipv6.h | 1 +
include/uapi/linux/ipv6.h | 1 +
include/uapi/linux/sysctl.h | 1 +
kernel/sysctl_binary.c | 1 +
net/ipv6/addrconf.c | 9 +++++++++
net/ipv6/ndisc.c | 2 +-
7 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 85b0221..da50faa 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1287,6 +1287,13 @@ accept_ra_rtr_pref - BOOLEAN
Functional default: enabled if accept_ra is enabled.
disabled if accept_ra is disabled.
+accept_ra_mtu - BOOLEAN
+ Apply the MTU value specified in RA option 5 (RFC4861). If
+ disabled, the MTU specified in the RA will be ignored.
+
+ Functional default: enabled if accept_ra is enabled.
+ disabled if accept_ra is disabled.
+
accept_redirects - BOOLEAN
Accept Redirects.
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index c694e7b..2805062 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -52,6 +52,7 @@ struct ipv6_devconf {
__s32 force_tllao;
__s32 ndisc_notify;
__s32 suppress_frag_ndisc;
+ __s32 accept_ra_mtu;
void *sysctl;
};
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 73cb02d..437a6a4 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -169,6 +169,7 @@ enum {
DEVCONF_SUPPRESS_FRAG_NDISC,
DEVCONF_ACCEPT_RA_FROM_LOCAL,
DEVCONF_USE_OPTIMISTIC,
+ DEVCONF_ACCEPT_RA_MTU,
DEVCONF_MAX
};
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 0956373..45e4fcf 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -570,6 +570,7 @@ enum {
NET_IPV6_PROXY_NDP=23,
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
NET_IPV6_ACCEPT_RA_FROM_LOCAL=26,
+ NET_IPV6_ACCEPT_RA_MTU=27,
__NET_IPV6_MAX
};
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 7e7746a..16091e5 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -523,6 +523,7 @@ static const struct bin_table bin_net_ipv6_conf_var_table[] = {
{ CTL_INT, NET_IPV6_PROXY_NDP, "proxy_ndp" },
{ CTL_INT, NET_IPV6_ACCEPT_SOURCE_ROUTE, "accept_source_route" },
{ CTL_INT, NET_IPV6_ACCEPT_RA_FROM_LOCAL, "accept_ra_from_local" },
+ { CTL_INT, NET_IPV6_ACCEPT_RA_MTU, "accept_ra_mtu" },
{}
};
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f7c8bbe..cdd70ed 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -201,6 +201,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
.disable_ipv6 = 0,
.accept_dad = 1,
.suppress_frag_ndisc = 1,
+ .accept_ra_mtu = 1,
};
static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -238,6 +239,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.disable_ipv6 = 0,
.accept_dad = 1,
.suppress_frag_ndisc = 1,
+ .accept_ra_mtu = 1,
};
/* Check if a valid qdisc is available */
@@ -5253,6 +5255,13 @@ static struct addrconf_sysctl_table
.proc_handler = proc_dointvec,
},
{
+ .procname = "accept_ra_mtu",
+ .data = &ipv6_devconf.accept_ra_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
/* sentinel */
}
},
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6828667..8a9d7c1 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1348,7 +1348,7 @@ skip_routeinfo:
}
}
- if (ndopts.nd_opts_mtu) {
+ if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
__be32 n;
u32 mtu;
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply related
* RE: [PATCH net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-19 21:31 UTC (permalink / raw)
To: 'David Miller'; +Cc: netdev
In-Reply-To: <20150119.155807.377681769985591321.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, January 19, 2015 1:58 PM
> To: harouth@codeaurora.org
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] net: ipv6: Add sysctl entry to disable MTU
> updates from RA
>
> From: Harout Hedeshian <harouth@codeaurora.org>
> Date: Fri, 16 Jan 2015 18:02:38 -0700
>
> > The kernel forcefully applies MTU values received in router
> > advertisements provided the new MTU is less than the current. This
> > behavior is undesirable when the user space is managing the MTU.
> > Instead a sysctl flag 'accept_ra_mtu' is introduced such that the user
> > space can control whether or not RA provided MTU updates should be
> > applied. The default behavior is unchanged; user space must explicitly
> > set this flag to 0 for RA MTUs to be ignored.
> >
> > Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
>
> A really sloppy submission, sorry I can't apply this.
>
> > + { CTL_INT, NET_IPV6_ACCEPT_RA_MTU,
> "accept_ra_mtu" },
Yes, it appears include/uapi/linux/sysctl.h was missed during a rebase. I
will correct this.
> This isn't defined anywhere, you left out some file while creating your
patch.
>
> kernel/sysctl_binary.c:526:13: error: ?NET_IPV6_ACCEPT_RA_MTU?
> undeclared here (not in a function)
>
>
> > - if (ndopts.nd_opts_mtu) {
> > + if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
>
> Too many spaced before the &&
Hmm. Looks like checkpatch.pl did does not catch this mistake. I only get
one warning about a line being too long:
harouth@harouth-lnx:/local/vg_local/lv_mainline/net_next/net-next$
./scripts/checkpatch.pl
0001-net-ipv6-Add-sysctl-entry-to-disable-MTU-updates-fro.patch
WARNING: line over 80 characters
#74: FILE: kernel/sysctl_binary.c:526:
+ { CTL_INT, NET_IPV6_ACCEPT_RA_MTU,
"accept_ra_mtu" },
total: 0 errors, 1 warnings, 0 checks, 69 lines checked
0001-net-ipv6-Add-sysctl-entry-to-disable-MTU-updates-fro.patch has style
problems, please review.
I will send an updated patch (v2) in a moment.
V2 patch passes compilation in sysctl_binary.c:
harouth@harouth-lnx:/local/vg_local/lv_mainline/net_next/net-next$ make -j8
ARCH=um
..
CC kernel/sysctl.o
CC kernel/sysctl_binary.o
..
Thanks,
Harout
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
^ permalink raw reply
* Re: ipvlan: Initial check-in of the IPVLAN driver.
From: David Miller @ 2015-01-19 21:20 UTC (permalink / raw)
To: dan.carpenter; +Cc: maheshb, netdev
In-Reply-To: <20150119144011.GA19086@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 19 Jan 2015 17:40:11 +0300
> The patch 2ad7bf363841: "ipvlan: Initial check-in of the IPVLAN
> driver." from Nov 23, 2014, leads to the following static checker
> warning:
>
> drivers/net/ipvlan/ipvlan_core.c:380 ipvlan_process_v6_outbound()
> warn: 'dst' isn't an ERR_PTR
>
> drivers/net/ipvlan/ipvlan_core.c
> 378
> 379 dst = ip6_route_output(dev_net(dev), NULL, &fl6);
> 380 if (IS_ERR(dst))
> 381 goto err;
>
> The ip6_route_output() function is not documented but it always returns
> a valid pointer. I believe you are supposed to check something like:
>
> if (dst->error) {
> ret = dst->error;
> goto error;
> }
>
> 382
> 383 skb_dst_drop(skb);
> 384 skb_dst_set(skb, dst);
This is correct.
^ permalink raw reply
* Re: [PATCH] phonet netlink: allow multiple messages per skb in route dump
From: David Miller @ 2015-01-19 21:20 UTC (permalink / raw)
To: johannes; +Cc: netdev, sakari.ailus, courmisch, johannes.berg
In-Reply-To: <1421666124-16055-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 19 Jan 2015 12:15:24 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> My previous patch to this file changed the code to be bug-compatible
> towards userspace. Unless userspace (which I wasn't able to find)
> implements the dump reader by hand in a wrong way, this isn't needed.
> If it uses libnl or similar code putting multiple messages into a
> single SKB is far more efficient.
>
> Change the code to do this. While at it, also clean it up and don't
> use so many variables - just store the address in the callback args
> directly.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] r8152: couldn't read OCP_SRAM_DATA
From: David Miller @ 2015-01-19 21:18 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-126-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 19 Jan 2015 17:02:44 +0800
> Read OCP_SRAM_DATA would read additional bytes and may let
> the hw abnormal.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/5] bonding: keep bond interface carrier off until at least one active member
From: Jay Vosburgh @ 2015-01-19 21:16 UTC (permalink / raw)
To: Jonathan Toppins
Cc: netdev, Scott Feldman, Andy Gospodarek, Veaceslav Falico,
Nikolay Aleksandrov
In-Reply-To: <1421423848-414-2-git-send-email-jtoppins@cumulusnetworks.com>
Jonathan Toppins <jtoppins@cumulusnetworks.com> wrote:
>From: Scott Feldman <sfeldma@cumulusnetworks.com>
>
>Bonding driver parameter min_links is now used to signal upper-level
>protocols of bond status. The way it works is if the total number of
>active members in slaves drops below min_links, the bond link carrier
>will go down, signaling upper levels that bond is inactive. When active
>members returns to >= min_links, bond link carrier will go up (RUNNING),
>and protocols can resume. When bond is carrier down, member ports are
>in stp fwd state blocked (rather than normal disabled state), so
>low-level ctrl protocols (LACP) can still get in and be processed by
>bonding driver.
Presuming that "stp" is Spanning Tree, is the last sentence
above actually describing the behavior of a bridge port when a bond is
the member of the bridge? I'm not sure I understand what "member ports"
refers to (bridge ports or bonding slaves).
One code comment, below...
>LACP will still do it's job while bond is carrier off, and if bond members
>become active, bond carrier will be turned back on, signaling higher-level
>protocols that bond is viable.
>
>Suggested setting of min_links is 1, rather than the default of zero.
>Using min_links=1 says that at least 1 slave must be active within bond
>for bond to be carrier on.
>
>Finally, when min_links bonding option is changed update carrier status.
>
>Cc: Scott Feldman <sfeldma@gmail.com>
>Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
>Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
>---
> drivers/net/bonding/bond_3ad.c | 18 ++++++++++++++----
> drivers/net/bonding/bond_main.c | 2 +-
> drivers/net/bonding/bond_options.c | 1 +
> include/net/bonding.h | 1 +
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 8baa87d..e9b706f 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -189,6 +189,7 @@ static inline int __agg_has_partner(struct aggregator *agg)
> static inline void __disable_port(struct port *port)
> {
> bond_set_slave_inactive_flags(port->slave, BOND_SLAVE_NOTIFY_LATER);
>+ bond_3ad_set_carrier(port->slave->bond);
> }
>
> /**
>@@ -199,8 +200,10 @@ static inline void __enable_port(struct port *port)
> {
> struct slave *slave = port->slave;
>
>- if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave))
>+ if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave)) {
> bond_set_slave_active_flags(slave, BOND_SLAVE_NOTIFY_LATER);
>+ bond_3ad_set_carrier(slave->bond);
>+ }
> }
>
> /**
>@@ -2372,8 +2375,10 @@ void bond_3ad_handle_link_change(struct slave *slave, char link)
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> struct aggregator *active;
>- struct slave *first_slave;
>+ struct slave *first_slave, *slave;
>+ struct list_head *iter;
> int ret = 1;
>+ int active_slaves = 0;
>
> rcu_read_lock();
> first_slave = bond_first_slave_rcu(bond);
>@@ -2381,10 +2386,15 @@ int bond_3ad_set_carrier(struct bonding *bond)
> ret = 0;
> goto out;
> }
>+
>+ bond_for_each_slave_rcu(bond, slave, iter)
>+ if (SLAVE_AD_INFO(slave)->aggregator.is_active)
>+ active_slaves++;
>+
> active = __get_active_agg(&(SLAVE_AD_INFO(first_slave)->aggregator));
>- if (active) {
>+ if (active && __agg_has_partner(active)) {
Why "__agg_has_partner"? Since the "else" of this clause is:
} else if (netif_carrier_ok(bond->dev)) {
netif_carrier_off(bond->dev);
}
I'm wondering if this will do the right thing for the case that
there are no LACP partners at all (e.g., the switch ports do not have
LACP enabled), in which case the active aggregator should be a single
"individual" port as a fallback, but will not have a partner.
-J
> /* are enough slaves available to consider link up? */
>- if (active->num_of_ports < bond->params.min_links) {
>+ if (active_slaves < bond->params.min_links) {
> if (netif_carrier_ok(bond->dev)) {
> netif_carrier_off(bond->dev);
> goto out;
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 0dceba1..02ffedb 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -334,7 +334,7 @@ static int bond_vlan_rx_kill_vid(struct net_device *bond_dev,
> *
> * Returns zero if carrier state does not change, nonzero if it does.
> */
>-static int bond_set_carrier(struct bonding *bond)
>+int bond_set_carrier(struct bonding *bond)
> {
> struct list_head *iter;
> struct slave *slave;
>diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
>index 9bd538d4..4df2894 100644
>--- a/drivers/net/bonding/bond_options.c
>+++ b/drivers/net/bonding/bond_options.c
>@@ -1181,6 +1181,7 @@ static int bond_option_min_links_set(struct bonding *bond,
> netdev_info(bond->dev, "Setting min links value to %llu\n",
> newval->value);
> bond->params.min_links = newval->value;
>+ bond_set_carrier(bond);
>
> return 0;
> }
>diff --git a/include/net/bonding.h b/include/net/bonding.h
>index 983a94b..29f53ea 100644
>--- a/include/net/bonding.h
>+++ b/include/net/bonding.h
>@@ -525,6 +525,7 @@ void bond_sysfs_slave_del(struct slave *slave);
> int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev);
> int bond_release(struct net_device *bond_dev, struct net_device *slave_dev);
> u32 bond_xmit_hash(struct bonding *bond, struct sk_buff *skb);
>+int bond_set_carrier(struct bonding *bond);
> void bond_select_active_slave(struct bonding *bond);
> void bond_change_active_slave(struct bonding *bond, struct slave *new_active);
> void bond_create_debugfs(void);
>--
>1.7.10.4
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net-next 1/7] r8152: adjust rx_bottom
From: David Miller @ 2015-01-19 21:13 UTC (permalink / raw)
To: sfeldma-Re5JQEeQqe8AvxtiuMwx3w
Cc: hayeswang-Rasf1IRRPZFBDgjK7y7TUQ, netdev-u79uwXL29TY76Z2rM5mHXA,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAE4R7bAv26f-+DW-TmjspJxAb-3Add5sf563mnMUTGCyiqG3rQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Scott Feldman <sfeldma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 19 Jan 2015 00:03:42 -0800
> On Sun, Jan 18, 2015 at 11:13 PM, Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org> wrote:
>> @@ -1746,7 +1746,18 @@ find_next_rx:
>> }
>>
>> submit:
>> - r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> + if (!ret) {
>> + ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> + } else {
>> + urb->actual_length = 0;
>> + list_add_tail(&agg->list, next);
>
> Do you need a spin_lock_irqsave(&tp->rx_lock, flags) around this?
Indeed, and rtl_start_rx() seems to also access agg->list without
proper locking.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] i40e: don't enable and init FCOE by default when do PF reset
From: Dev, Vasu @ 2015-01-19 21:10 UTC (permalink / raw)
To: ethan zhao, Kirsher, Jeffrey T
Cc: e1000-devel@lists.sourceforge.net, brian.maly@oracle.com,
Allan, Bruce W, Brandeburg, Jesse, Parikh, Neerav, Linux NICS,
Ronciak, John, netdev@vger.kernel.org, Ethan Zhao,
linux-kernel@vger.kernel.org
In-Reply-To: <54B9D082.9050601@oracle.com>
> -----Original Message-----
> From: ethan zhao [mailto:ethan.zhao@oracle.com]
> Sent: Friday, January 16, 2015 7:01 PM
> To: Kirsher, Jeffrey T
> Cc: Dev, Vasu; Ethan Zhao; Ronciak, John; Brandeburg, Jesse; Allan, Bruce W;
> Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Vick, Matthew;
> Williams, Mitch A; Parikh, Neerav; Linux NICS; e1000-
> devel@lists.sourceforge.net; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; brian.maly@oracle.com
> Subject: Re: [PATCH] i40e: don't enable and init FCOE by default when do PF
> reset
>
> Vasu,
>
> What' your idea about the v2, any suggestion ? Jeff is looking forward to
> see it.
>
Jeff was asking for v2 in response to your last comment as "disable FCOE as default configuration as a temporary step" but I think that is the fix and user should n't enable FCoE until they have FCoE enabled X710 FCoE with either fabric or VN2VN mode FCoE setup.
Thanks,
Vasu
> Thanks,
> Ethan
>
>
> On 2015/1/16 22:47, Jeff Kirsher wrote:
> > On Fri, 2015-01-16 at 09:48 +0800, ethan zhao wrote:
> >> Vasu,
> >>
> >> OK, disable FCOE as default configuration as a temporary step to
> >> make it work.
> > Sounds like I should expect a v2 coming, correct?
> >
> >>
> >> Thanks,
> >> Ethan
> >>
> >> On 2015/1/16 7:45, Dev, Vasu wrote:
> >>>> -----Original Message-----
> >>>> From: ethan zhao [mailto:ethan.zhao@oracle.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@lists.sourceforge.net; netdev@vger.kernel.org;
> >>>> linux- kernel@vger.kernel.org; brian.maly@oracle.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@intel.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@vger.kernel.org>
> >>>>>>> Signed-off-by: Vasu Dev <vasu.dev@intel.com>
> >>>>>>> Tested-by: Jim Young <jamesx.m.young@intel.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
> >
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox