Re: [GIT] Networking

On Wed, Sep 6, 2017 at 10:40 PM, Luca Coelho wrote: > > This patch is not very important (unless you really like blinking lights > -- maybe I'll change my mind when the holidays approach :P). so it is > fine if you just want to revert it for now. > > In any case, I'll send a patch

Re: [GIT] Networking

On Thu, 2017-09-07 at 05:04 +, Coelho, Luciano wrote: > On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote: > > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano > > wrote: > > > > > > This seems to be a problem with backwards-compatibility with FW version > > >

Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces for traffic shapers

On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote: > Hi, > > This patchset is an RFC on a proposal of how the Traffic Control subsystem can > be used to offload the configuration of traffic shapers into network devices > that provide support for them in HW. Our goal here is to

[LPC] 2nd RDMA Mini-Summit Schedule

Hi, We're happy to announce schedule of the 2nd RDMA mini-summit, which will be held as part of coming Linux Plumbers Conference 2017. During the conference, we will have two sessions: main track session and round table session. First session will be held on Thursday, September 14, 2017 from

Re: ipset losing entries on its own

What I observed is rehashing of set is not happening. When I add multiple IPs to the ipset manually on ipset v6.32, rehashing is not happening and my hashsize remains same as 1024 but when I add to ipset 4.5 (pretty old, I know!), rehashing is happening and my hashsize changes from 1024 to 1536

WARNING: at net/netfilter/core.c:218 __nf_hook_entries_try_shrink+0xf7/0x110

[ 21.219604] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 21.433091] nf_conntrack version 0.5.0 (65536 buckets, 262144 max) [ 21.495849] ip_tables: (C) 2000-2006 Netfilter Core Team [ 22.404040] [ cut here ] [ 22.404267] WARNING: CPU: 2 PID: 1379 at

Re: [GIT] Networking

On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote: > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano > wrote: > > > > This seems to be a problem with backwards-compatibility with FW version > > 27. We are now in version 31[1] and upgrading will probably fix that.

Re: [GIT] Networking

On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano wrote: > > This seems to be a problem with backwards-compatibility with FW version > 27. We are now in version 31[1] and upgrading will probably fix that. I can confirm that fw version 31 works. > But obviously the

Re: ipset losing entries on its own

I understand that without reproducible scenarios, its hard to debug ... But the point is, this issue is fully random and of very low frequency. For the setup, it is CentOS 7.3 upgraded to kernel 4.4. Whenever a system comes up on the network, he provides his credentials and after successful

Re: [PATCH] tipc: remove unnecessary call to dev_net()

From: Kleber Sacilotto de Souza Date: Wed, 6 Sep 2017 11:08:06 +0200 > The net device is already stored in the 'net' variable, so no need to call > dev_net() again. > > Signed-off-by: Kleber Sacilotto de Souza Applied, thanks.

[Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

This patch fixes the following madness of tc filter chain: 1) tcf_chain_destroy() is called by both tcf_block_put() and tcf_chain_put(). tcf_chain_put() is correctly refcnt'ed and paired with tcf_chain_get(), but tcf_block_put() is not, it should be paired with tcf_block_get() which

[Patch net v2 1/2] net_sched: get rid of tcfa_rcu

gen estimator has been rewritten in commit 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators"), the caller is no longer needed to wait for a grace period. So this patch gets rid of it. This also completely closes a race condition between action free path and filter

Re: [PATCH net] netlink: access nlk groups safely in netlink bind and getname

From: Xin Long Date: Wed, 6 Sep 2017 11:53:29 +0800 > Now there is no lock protecting nlk ngroups/groups' accessing in > netlink bind and getname. It's safe from nlk groups' setting in > netlink_release, but not from netlink_realloc_groups called by > netlink_setsockopt. >

Re: [PATCH net] netlink: fix an use-after-free issue for nlk groups

From: Xin Long Date: Wed, 6 Sep 2017 11:47:12 +0800 > ChunYu found a netlink use-after-free issue by syzkaller: > > [28448.842981] BUG: KASAN: use-after-free in __nla_put+0x37/0x40 at addr > 8807185e2378 > [28448.969918] Call Trace: > [...] > [28449.117207]

Re: [PATCH] dt-binding: phy: don't confuse with Ethernet phy properties

From: Baruch Siach Date: Sun, 3 Sep 2017 17:32:16 +0300 > The generic PHY 'phys' property sometime appears in the same node with > the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in > phy-bindings.txt to reduce confusion. > > Signed-off-by: Baruch Siach

Re: [GIT] Networking

On Wed, 2017-09-06 at 16:27 -0700, Linus Torvalds wrote: > This pull request completely breaks Intel wireless for me. > > This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a). > > That remains a very standard Intel machine with absolutely zero odd > things going on. > > The

[PATCH] ipv4: Namespaceify tcp_max_orphans knob

Different namespace application might require different maximal number of TCP sockets independently of the host. Signed-off-by: Haishuang Yan --- include/net/netns/ipv4.h | 1 + include/net/tcp.h | 5 +++-- net/ipv4/sysctl_net_ipv4.c | 14

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 05:10 PM, David Daney wrote: > On 09/06/2017 04:14 PM, Florian Fainelli wrote: >> On 09/06/2017 03:51 PM, David Daney wrote: > [...] >>> >>> Consider instead the case of a Marvell phy with no interrupts connected >>> on a v4.9.43 kernel, single CPU: >>> >>> >>>0)

LOAN AVAILABLE @3 %

LOAN AVAILABLE @3 % Rely mohammedanis...@gmail.com

Re: [PATCH net 1/2] i40e: Fix comment about locking for __i40e_read_nvm_word()

On Wed, 2017-09-06 at 10:11 +0200, Stefano Brivio wrote: > Caller needs to acquire the lock. Called functions will not. > > Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM > update") > Signed-off-by: Stefano Brivio > --- >

Re: [PATCH net 2/2] i40e: Avoid some useless variables and initializers in nvm functions

On Wed, 2017-09-06 at 10:11 +0200, Stefano Brivio wrote: > Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM > update") > Signed-off-by: Stefano Brivio > --- > drivers/net/ethernet/intel/i40e/i40e_nvm.c | 20 +++- > 1 file changed, 7

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

> At the very least we should probably move the skb->offload_fwd_mark > setting down into the individual taggers since they should be in a > better position to set it or not based on the switch device they are > driving, this should address, on a per-switch basis whether 2) or 3) > applies to a

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On Wed, Sep 06, 2017 at 11:44:47PM +, woojung@microchip.com wrote: > > That being said, I have a feeling that the Marvell switches behave a > > tiny bit differently than others in that they do not flood broadcast by > > default in a given L2 domain. > Florian, > > Because some DSA

[PATCH RFC v1 2/3] net: Abstracting out common routines from veth for use by vethtap

From: Sainath Grandhi Abstracting out common routines for link operations in veth implementation for use by vethtap interfaces Signed-off-by: Sainath Grandhi --- drivers/net/veth.c | 47 +--

[PATCH RFC v1 3/3] vethtap: veth based tap driver

From: Sainath Grandhi This patch adds a tap character device driver that is based on the veth network interface, called vethtap. This patchset allows vethtap device to be created ONLY as a peer interface to a veth network interface. It can be created in the following

[PATCH RFC v1 1/3] net: Adding API to parse IFLA_LINKINFO attribute

From: Sainath Grandhi Adding rtnl_nla_parse_ifla_info as an exported symbol in rtnetlink.c helps other modules to parse IFLA_LINKINFO attribute Signed-off-by: Sainath Grandhi --- include/net/rtnetlink.h | 3 +++ net/core/rtnetlink.c| 8

[PATCH RFC v1 0/3] Support for tap user-space access with veth interfaces

From: Sainath Grandhi This patchset adds a tap device driver for veth virtual network interface. With this implementation, tap character interface can be added only to the peer veth interface. Adding tap interface to veth is for usecases that forwards packets between

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 04:14 PM, Florian Fainelli wrote: On 09/06/2017 03:51 PM, David Daney wrote: [...] Consider instead the case of a Marvell phy with no interrupts connected on a v4.9.43 kernel, single CPU: 0) | phy_disconnect() { 0) |

RE: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

> That being said, I have a feeling that the Marvell switches behave a > tiny bit differently than others in that they do not flood broadcast by > default in a given L2 domain. Florian, Because some DSA switches from Marvell & Microchip can do IGMP snooping, can we propose switch layer another

Re: [patch net] net: sched: fix memleak for chain zero

On Wed, Sep 6, 2017 at 1:33 PM, Jiri Pirko wrote: > Wed, Sep 06, 2017 at 07:40:02PM CEST, xiyou.wangc...@gmail.com wrote: >>On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote: >>> From: Jiri Pirko >>> >>> There's a memleak happening for chain

Re: [GIT] Networking

On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds wrote: > > The firmware is iwlwifi-8000C-28.ucode from > iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports > > iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm And when I said

Re: [GIT] Networking

From: Linus Torvalds Date: Wed, 6 Sep 2017 16:27:15 -0700 > This pull request completely breaks Intel wireless for me. > > This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a). > > That remains a very standard Intel machine with absolutely zero

Re: [GIT] Networking

This pull request completely breaks Intel wireless for me. This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a). That remains a very standard Intel machine with absolutely zero odd things going on. The firmware is iwlwifi-8000C-28.ucode from

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 03:51 PM, David Daney wrote: > On 09/06/2017 01:49 PM, David Daney wrote: >> On 09/06/2017 11:59 AM, Florian Fainelli wrote: >>> On 09/06/2017 11:00 AM, David Daney wrote: On 08/31/2017 11:29 AM, Florian Fainelli wrote: > On 08/31/2017 11:12 AM, Mason wrote: >> On

[PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

Commit cbf5ecb30560 ("net: bonding: Fix transmit load balancing in balance-alb mode") tried to fix transmit dynamic load balancing in balance-alb mode, which wasn't working after commit 8b426dc54cf4 ("bonding: remove hardcoded value"). It turned out that my previous patch only fixed the case when

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode

Reinis Rozitis reported that tlb_dynamic_lb was still 0 in balance-alb mode even when using linux-4.12.10 kernels, which includes this patch. It turned out that my previous patch only fixed the case when balance-alb mode was specified as bonding module parameter, and not when balance-alb mode was

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 01:49 PM, David Daney wrote: On 09/06/2017 11:59 AM, Florian Fainelli wrote: On 09/06/2017 11:00 AM, David Daney wrote: On 08/31/2017 11:29 AM, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM,

Re: Fwd: DA850-evm MAC Address is random

On Mon, Sep 4, 2017 at 11:42 PM, Sekhar Nori wrote: > Hi Adam, > > On Wednesday 30 August 2017 11:08 AM, Sekhar Nori wrote: >>> I wonder if U-Boot isn't pushing something to Linux because it doesn't >>> appear to be running some of the da850 specific code even when I run >>>

[PATCH net] hv_netvsc: fix deadlock on hotplug

When a virtual device is added dynamically (via host console), then the vmbus sends an offer message for the primary channel. The processing of this message for networking causes the network device to then initialize the sub channels. The problem is that setting up the sub channels needs to wait

[PATCH v2 net-next 1/2] hv_netvsc: fix deadlock on hotplug

When a virtual device is added dynamically (via host console), then the vmbus sends an offer message for the primary channel. The processing of this message for networking causes the network device to then initialize the sub channels. The problem is that setting up the sub channels needs to wait

[PATCH v2 net-next 0/2] hv_netvsc: sub channel initialization fixes

One serious deadlock, and one minor optimization. Stephen Hemminger (2): hv_netvsc: fix deadlock on hotplug hv_netvsc: avoid unnecessary wakeups on subchannel creation drivers/net/hyperv/hyperv_net.h | 3 + drivers/net/hyperv/netvsc.c | 3 + drivers/net/hyperv/netvsc_drv.c |

[PATCH v2 net-next 2/2] hv_netvsc: avoid unnecessary wakeups on subchannel creation

Only need to wakeup the initiator after all sub-channels are opened. Signed-off-by: Stephen Hemminger --- drivers/net/hyperv/rndis_filter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/hyperv/rndis_filter.c

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 11:59 AM, Florian Fainelli wrote: On 09/06/2017 11:00 AM, David Daney wrote: On 08/31/2017 11:29 AM, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: On 31/08/2017 18:57, Florian

Re: [PATCH] netfilter: xt_hashlimit: avoid 64-bit division

On Wed, Sep 6, 2017 at 10:22 PM, Vishwanath Pai wrote: > On 09/06/2017 03:57 PM, Arnd Bergmann wrote: >> 64-bit division is expensive on 32-bit architectures, and >> requires a special function call to avoid a link error like: >> >> net/netfilter/xt_hashlimit.o: In function

Re: [patch net] net: sched: fix memleak for chain zero

Wed, Sep 06, 2017 at 07:40:02PM CEST, xiyou.wangc...@gmail.com wrote: >On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote: >> From: Jiri Pirko >> >> There's a memleak happening for chain 0. The thing is, chain 0 needs to >> be always present, not created on

[PATCH 13/14] netfilter/ipvs: Use %pS printk format for direct addresses

The debug and error printk functions in ipvs uses wrongly the %pF instead of the %pS printk format specifier for printing symbols for the address returned by _builtin_return_address(0). Fix it for the ia64, ppc64 and parisc64 architectures. Signed-off-by: Helge Deller Cc: Wensong

Re: [PATCH] netfilter: xt_hashlimit: avoid 64-bit division

On 09/06/2017 03:57 PM, Arnd Bergmann wrote: > 64-bit division is expensive on 32-bit architectures, and > requires a special function call to avoid a link error like: > > net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common': > xt_hashlimit.c:(.text+0x1328): undefined reference to

[PATCH] netfilter: xt_hashlimit: avoid 64-bit division

64-bit division is expensive on 32-bit architectures, and requires a special function call to avoid a link error like: net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common': xt_hashlimit.c:(.text+0x1328): undefined reference to `__aeabi_uldivmod' In the case of hashlimit_mt_common, we

Re: [net-next:master 491/511] xt_hashlimit.c:undefined reference to `__aeabi_uldivmod'

On Wed, Sep 6, 2017 at 5:27 PM, kbuild test robot wrote: > Hi Arnd, > > It's probably a bug fix that unveils the link errors. Correct. >net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common': >>> xt_hashlimit.c:(.text+0x1f68): undefined reference to

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 09/06/2017 09:42 AM, Andrew Lunn wrote: >>> On the switch asics we work with, the driver has information if the >>> packet was >>> forwarded in hardware. This is per packet reason code telling why the >>> CPU is seeing the packet. >>> The driver can use this information to reset

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 08:51 AM, Mason wrote: > On 31/08/2017 21:18, Florian Fainelli wrote: > >> On 08/31/2017 12:09 PM, Mason wrote: >> >>> On 31/08/2017 19:03, Florian Fainelli wrote: >>> On 08/31/2017 05:29 AM, Marc Gonzalez wrote: > On 31/08/2017 02:49, Florian Fainelli wrote: >

RE: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > Sent: Wednesday, September 6, 2017 7:11 AM >> ... > > I'm currently working on NFS over AF_VSOCK and sock_diag support (for > > ss(8) and netstat-like tools). > > > > Multi-transport support is lower priority for me at the moment. I'm > >

[wireless-testsing2:master 4/5] drivers/net//ethernet/marvell/mvpp2.c:7618:2: warning: passing argument 4 of 'mvpp2_port_copy_mac_addr' from incompatible pointer type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git master head: d17be7f7503bf9492198a242779a68af93fd92de commit: 96c03618031bae5e9068b16f9e437b79f98f6482 [4/5] Merge remote-tracking branch 'mac80211-next/master' config: xtensa-allyesconfig (attached as

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 07:55 AM, Mason wrote: > On 31/08/2017 21:18, Florian Fainelli wrote: > >> On 08/31/2017 12:09 PM, Mason wrote: >> >>> 1) nb8800_link_reconfigure() calls phy_print_status() >>> which prints the "Link down" and "Link up" messages >>> to the console. With the patch reverted, nothing

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 06/09/2017 20:00, David Daney wrote: > On 08/31/2017 11:29 AM, Florian Fainelli wrote: >> On 08/31/2017 11:12 AM, Mason wrote: >>> On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: > On 31/08/2017 18:57, Florian Fainelli wrote: >> And the race is

Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads

On Wed, Sep 6, 2017 at 10:43 AM, Alexander Duyck wrote: > On Wed, Sep 6, 2017 at 9:17 AM, Tom Herbert wrote: >> On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck >> wrote: >>> On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 11:00 AM, David Daney wrote: > On 08/31/2017 11:29 AM, Florian Fainelli wrote: >> On 08/31/2017 11:12 AM, Mason wrote: >>> On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: > On 31/08/2017 18:57, Florian Fainelli wrote: >> And the race is

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On 09/06/2017 08:42 PM, John Fastabend wrote: On 09/06/2017 11:18 AM, Jesper Dangaard Brouer wrote: On Wed, 06 Sep 2017 18:24:07 +0200 Daniel Borkmann wrote: On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote: Using bpf_redirect_map is allowed for generic XDP

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On 09/06/2017 11:18 AM, Jesper Dangaard Brouer wrote: > On Wed, 06 Sep 2017 18:24:07 +0200 > Daniel Borkmann wrote: > >> On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote: >>> Using bpf_redirect_map is allowed for generic XDP programs, but the >>> appropriate map lookup

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

Hi Andrew, Andrew Lunn writes: >> I don't understand why SWITCHDEV_OBJ_ID_PORT_MDB cannot be used. Isn't >> setting the obj->orig_dev to the bridge device itself enough to >> distinguish br0 from a switch port? > > I did consider this. But conceptually, it seems wrong. >

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On Wed, 06 Sep 2017 18:24:07 +0200 Daniel Borkmann wrote: > On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote: > > Using bpf_redirect_map is allowed for generic XDP programs, but the > > appropriate map lookup was never performed in xdp_do_generic_redirect(). > > > >

Re: [PATCH net-next RFC 2/2] tun: enable napi_gro_frags() for TUN/TAP driver

On Tue, 2017-09-05 at 15:35 -0700, Petar Penkov wrote: > Add a TUN/TAP receive mode that exercises the napi_gro_frags() > interface. This mode is available only in TAP mode, as the interface > expects packets with Ethernet headers. > Hi Petar, thanks a lot for this work. I must confess I have

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 08/31/2017 11:29 AM, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: On 31/08/2017 18:57, Florian Fainelli wrote: And the race is between phy_detach() setting phydev->attached_dev = NULL and

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 09/06/2017 07:33 AM, Mason wrote: On 31/08/2017 20:29, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: On 31/08/2017 18:57, Florian Fainelli wrote: And the race is between phy_detach() setting

Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads

On Wed, Sep 6, 2017 at 9:17 AM, Tom Herbert wrote: > On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck > wrote: >> On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert wrote: The situation with encapsulation is even more

Re: [patch net] net: sched: fix memleak for chain zero

On Wed, Sep 6, 2017 at 4:14 AM, Jiri Pirko wrote: > From: Jiri Pirko > > There's a memleak happening for chain 0. The thing is, chain 0 needs to > be always present, not created on demand. Therefore tcf_block_get upon > creation of block calls the

Re: [patch net] net: sched: fix memleak for chain zero

On Wed, 6 Sep 2017 13:14:19 +0200, Jiri Pirko wrote: > From: Jiri Pirko > > There's a memleak happening for chain 0. The thing is, chain 0 needs to > be always present, not created on demand. Therefore tcf_block_get upon > creation of block calls the tcf_chain_create function

RE: [PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend

Thanks, will make separate patch. > Hi Nisar > > > + else if ((ee->magic == LAN78XX_EEPROM_MAGIC) && > > +(ee->offset >= 0 && ee->offset < MAX_EEPROM_SIZE) && > > +(ee->len > 0 && (ee->offset + ee->len) <= > MAX_EEPROM_SIZE)) > > + ret =

RE: [PATCH net 2/4] lan78xx: Add fixed_phy device support for LAN7801 device

Thanks Andrew, will try to change as suggested. > On Wed, Sep 06, 2017 at 10:51:44AM +, nisar.sa...@microchip.com > wrote: > > From: Nisar Sayed > > > > Add fixed_phy device support for LAN7801 device > > > > When LAN7801 device connected to PHY Device which does

RE: [PATCH net 1/4] lan78xx: Fix for crash associated with System suspend

Thanks Andrew inputs. > On Wed, Sep 06, 2017 at 10:51:31AM +, nisar.sa...@microchip.com > wrote: > > From: Nisar Sayed > > > > Fix for crash associated with System suspend > > > > Since ndo_stop removes phydev which makes phydev NULL. > > Whenever system suspend

Re: [Patch net] net_sched: fix a memory leak of filter chain

On Wed, Sep 6, 2017 at 12:38 AM, Jiri Pirko wrote: > Wed, Sep 06, 2017 at 07:03:10AM CEST, xiyou.wangc...@gmail.com wrote: >>tcf_chain_destroy() is called by tcf_block_put() and tcf_chain_put(). >>tcf_chain_put() is refcn'ed and paired with tcf_chain_get(), >>but tcf_block_put()

Re: [PATCH] DSA support for Micrel KSZ8895

> The patches are under review internally and will need to be updated > and approved by Woojung before formal submission. Problem is > although KSZ8795 and KSZ8895 drivers are new code and will be > submitted as RFC, they depend on the change of KSZ9477 driver > currently in the kernel, which

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On 09/06/2017 06:24 PM, Daniel Borkmann wrote: [...] Otherwise it looks good, but note that it also doesn't really resolve the issue you mention wrt stale map pointers by the way. This would need a different way to clear out the pointers from redirect_info, I'm thinking when we have devmap

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On Wed, Sep 06, 2017 at 11:25:26AM -0400, Vivien Didelot wrote: > Hi Andrew, Nikolay, > > Andrew Lunn writes: > > > Then starts the work passing down to the hardware that the host has > > joined/left a group. The existing switchdev mdb object cannot be used, > > since the

[iproute PATCH] utils: Review strlcpy() and strlcat()

As David Laight correctly pointed out, the first version of strlcpy() modified dst buffer behind the string copied into it. Fix this by writing NUL to the byte immediately following src string instead of to the last byte in dst. Doing so also allows to reduce overhead by using memcpy(). Improve

RE: [PATCH] DSA support for Micrel KSZ8895

> -Original Message- > From: Maxim Uvarov [mailto:muva...@gmail.com] > Sent: Wednesday, September 06, 2017 2:15 AM > To: Tristram Ha - C24268 > Cc: Pavel Machek; Woojung Huh - C21699; Nathan Conrad; Vivien Didelot; > Florian Fainelli; netdev; linux-ker...@vger.kernel.org; Andrew Lunn >

Re: [PATCH net v2] rds: Fix incorrect statistics counting

On 9/6/2017 9:35 AM, Håkon Bugge wrote: In rds_send_xmit() there is logic to batch the sends. However, if another thread has acquired the lock and has incremented the send_gen, it is considered a race and we yield. The code incrementing the s_send_lock_queue_raced statistics counter did not

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

> >On the switch asics we work with, the driver has information if the > >packet was > >forwarded in hardware. This is per packet reason code telling why the > >CPU is seeing the packet. > >The driver can use this information to reset skb->offload_fwd_mark to > >allow software forward. > I am not

[PATCH net v2] rds: Fix incorrect statistics counting

In rds_send_xmit() there is logic to batch the sends. However, if another thread has acquired the lock and has incremented the send_gen, it is considered a race and we yield. The code incrementing the s_send_lock_queue_raced statistics counter did not count this event correctly. This commit

Re: [PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug

On Wed, 6 Sep 2017 16:23:45 + Haiyang Zhang wrote: > > -Original Message- > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Wednesday, September 6, 2017 11:19 AM > > To: KY Srinivasan ; Haiyang Zhang > >

Re: [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID

> >Yes, you are correct. I will change this. > > A switch cluster should be tied to the same dsa_switch_tree though, > can we use dst->tree as an unique identifier? Yes, that is what Vivien was suggesting. Andrew

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote: Using bpf_redirect_map is allowed for generic XDP programs, but the appropriate map lookup was never performed in xdp_do_generic_redirect(). Instead the map-index is directly used as the ifindex. For the Good point, but ... [...]

RE: [PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug

> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, September 6, 2017 11:19 AM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > Cc:

Re: [PATCH net] rds: Fix incorrect statistics counting

On 9/6/2017 9:12 AM, Håkon Bugge wrote: [...] Hi Santosh, Yes, I agree with accuracy of s_send_lock_queue_raced. But the main point is that the existing code counts some partial share of when it is _not_ raced. So, in the critical path, my patch adds one test_bit(), which hits the local

Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads

On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck wrote: > On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert wrote: >>> The situation with encapsulation is even more complicated: >>> >>> We are basically only interested in the UDP/vxlan/Ethernet/IP/UDP

Re: [PATCH net] rds: Fix incorrect statistics counting

> On 6 Sep 2017, at 17:58, Santosh Shilimkar > wrote: > > On 9/6/2017 8:29 AM, Håkon Bugge wrote: >> In rds_send_xmit() there is logic to batch the sends. However, if >> another thread has acquired the lock, it is considered a race and we >> yield. The code

Re: [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID

On September 6, 2017 8:08:25 AM PDT, Andrew Lunn wrote: >> > Use the MAC address of the master interface as the parent ID. This >is >> > the same for all switches in a cluster, and should be unique if >there >> > are multiple clusters. >> >> That is not correct. Support for

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On September 6, 2017 8:54:33 AM PDT, Roopa Prabhu wrote: >On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn wrote: >>> The third and last issue will be explained in a followup email. >> >> Hi DSA hackers >> >> So there is the third issue. It affects just

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On Wed, 6 Sep 2017 11:44:18 -0400 Andy Gospodarek wrote: > On Wed, Sep 6, 2017 at 11:26 AM, Jesper Dangaard Brouer > wrote: > > Using bpf_redirect_map is allowed for generic XDP programs, but the > > appropriate map lookup was never performed in

Re: [PATCH net] rds: Fix incorrect statistics counting

On 9/6/2017 8:29 AM, Håkon Bugge wrote: In rds_send_xmit() there is logic to batch the sends. However, if another thread has acquired the lock, it is considered a race and we yield. The code incrementing the s_send_lock_queue_raced statistics counter did not count this event correctly. This

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn wrote: >> The third and last issue will be explained in a followup email. > > Hi DSA hackers > > So there is the third issue. It affects just DSA, but it possible > affects all DSA drivers. > > This patchset broken broadcast with the

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 21:18, Florian Fainelli wrote: On 08/31/2017 12:09 PM, Mason wrote: On 31/08/2017 19:03, Florian Fainelli wrote: On 08/31/2017 05:29 AM, Marc Gonzalez wrote: On 31/08/2017 02:49, Florian Fainelli wrote: The original motivation for this change originated from Marc Gonzalez

RE: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

Andrew, > What i found is that the Marvell chips don't flood broadcast frames > between bridged ports. What appears to happen is there is a fdb miss, > so it gets forwarded to the CPU port for the host to deal with. The > software bridge when floods it out all ports of the bridge. Is this IGMP

Re: hung task in mac80211

i confirm this patch fixes the issue for me as well Am 06.09.2017 um 17:04 schrieb Matteo Croce: On Wed, Sep 6, 2017 at 2:58 PM, Johannes Berg wrote: On Wed, 2017-09-06 at 13:57 +0200, Matteo Croce wrote: I have an hung task on vanilla 4.13 kernel which I haven't

Re: VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)

Hi Johannes and all, > > In a way this feature seems mis-designed - you never have 802.1Q tags > > over the air, but you're inserting them on RX and stripping them on > > TX, probably in order to make bridging to ethernet easier and not > > have to have 802.1Q acceleration on the ethernet port,

Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

On Wed, Sep 6, 2017 at 11:26 AM, Jesper Dangaard Brouer wrote: > Using bpf_redirect_map is allowed for generic XDP programs, but the > appropriate map lookup was never performed in xdp_do_generic_redirect(). > > Instead the map-index is directly used as the ifindex. For the >

Re: [PATCH v2 rfc 4/8] net: dsa: slave: Handle switchdev host mdb add/del

Hi Andrew, Andrew Lunn writes: > Add code to handle switchdev host mdb add/del. As with normal mdb > add/del, send a notification to the switch layer. > > Signed-off-by: Andrew Lunn > --- > net/dsa/dsa_priv.h | 7 +++ > net/dsa/port.c | 26

Fw: [Bug 196839] New: use_time of IPsec policy is updated even when receiving error packets.

Begin forwarded message: Date: Wed, 06 Sep 2017 10:18:33 + From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 196839] New: use_time of IPsec policy is updated even when receiving error packets. https://bugzilla.kernel.org/show_bug.cgi?id=196839

[PATCH net] rds: Fix incorrect statistics counting

In rds_send_xmit() there is logic to batch the sends. However, if another thread has acquired the lock, it is considered a race and we yield. The code incrementing the s_send_lock_queue_raced statistics counter did not count this event correctly. This commit removes a small race in determining

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

Hi Andrew, Nikolay, Andrew Lunn writes: > Then starts the work passing down to the hardware that the host has > joined/left a group. The existing switchdev mdb object cannot be used, > since the semantics are different. The existing > SWITCHDEV_OBJ_ID_PORT_MDB is used to

  1   2   >