RE: [PATCH net-next] qed: Add Light L2 [ll2] infrastructure

> > As I've mentioned in latest submissions, we're planning on pushing > > qedi and qedr and both would utilize it. > > I have no idea what qedi and qedr are. 'I' stands for iscsi driver. 'r' stands for roce driver.

Re: [PATCH net-next] qed: Add Light L2 [ll2] infrastructure

From: Yuval Mintz Date: Thu, 16 Jun 2016 05:27:30 + > As I've mentioned in latest submissions, we're planning on pushing > qedi and qedr and both would utilize it. I have no idea what qedi and qedr are.

RE: [PATCH net-next] qed: Add Light L2 [ll2] infrastructure

> > The qed driver will allow support for several drivers other than qede, > > and each of said protocol drivers will require some sort of L2-like > > ability to send and receive traffic - the common use-case would be for > > control traffic specific for the protocol that needs to reach > >

Re: [PATCH net-next 00/17] sfc: RX VLAN filtering

From: Edward Cree Date: Wed, 15 Jun 2016 17:39:56 +0100 > Adds support for VLAN-qualified receive filters on EF10 hardware. > This is needed when running as a guest if the hypervisor has enabled > vfs-vlan-restrict, in which case the firmware rejects filters not qualified >

Re: [PATCH net-next 0/8] rxrpc: Rework endpoint record handling

og/?h=rxrpc-rewrite > > Tagged thusly: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-rewrite-20160615 Pulled, thanks David.

Re: [PATCH 0/4] net-next: mediatek: IRQ cleanups, fixes and grouping

From: John Crispin Date: Wed, 15 Jun 2016 16:58:46 +0200 > This series contains 2 small code cleanups that are leftovers from the > MIPS support. There is also a small fix that adds proper locking to the > code accessing the IRQ registers. Without this fix we saw deadlocks

Re: [PATCH net-next] qed: Add Light L2 [ll2] infrastructure

From: Yuval Mintz Date: Wed, 15 Jun 2016 13:22:37 +0300 > The qed driver will allow support for several drivers other than > qede, and each of said protocol drivers will require some sort of > L2-like ability to send and receive traffic - > the common use-case would be

Re: [PATCH v2 net] gre: fix error handler

From: Eric Dumazet Date: Wed, 15 Jun 2016 06:24:00 -0700 > From: Eric Dumazet > > 1) gre_parse_header() can be called from gre_err() > >At this point transport header points to ICMP header, not the inner > header. > > 2) We can not really

Re: [PATCH] net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG

From: "Jason A. Donenfeld" Date: Wed, 15 Jun 2016 11:14:53 +0200 > The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG > case was added with 2c94b5373 ("net: Implement net_dbg_ratelimited() for > CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to

Re: [PATCH v2 09/11] net: skfb: remove obsolete -I cflag

From: Arnd Bergmann Date: Wed, 15 Jun 2016 17:45:51 +0200 > The skfp driver has been moved to drivers/net/fddi/skfp a long time > ago, but we still attempt to include headers from the old location, > which causes a warning when building with W=1: > > cc1: error:

Re: [PATCH] [v5] net: emac: emac gigabit ethernet controller driver

David Miller wrote: Please always order local variable declarations from longest to shortest line. Audit your entire driver for this issue, thanks. I will fix this in v6. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the

Re: [PATCH] tipc: fix suspicious RCU usage

From: Ying Xue Date: Wed, 15 Jun 2016 14:10:57 +0800 > When run tipcTS test suite, the following complaint appears: ... > The warning appears as rtnl_dereference() is wrongly used in > tipc_l2_send_msg() under RCU read lock protection. Instead the proper > usage should

Re: [PATCH] tipc: eliminate uninitialized variable warning

From: Ying Xue Date: Wed, 15 Jun 2016 14:11:31 +0800 > net/tipc/link.c: In function ‘tipc_link_timeout’: > net/tipc/link.c:744:28: warning: ‘mtyp’ may be used uninitialized in this > function [-Wuninitialized] > > Fixes: 42b18f605fea ("tipc: refactor function

Re: [PATCH net-next V2 0/9] liquidio: Updates and Bug fixes

From: Raghu Vatsavayi Date: Tue, 14 Jun 2016 16:54:42 -0700 > Following are updates for liquidio bug fixes and driver > support for new firmware interface. These updates are divided > into smaller logical patches as mentioned by you. These set of > nine patches

Re: [PATCH net-next] ila: Fix checksum neutral mapping

From: Tom Herbert Date: Tue, 14 Jun 2016 16:29:15 -0700 > The algorithm for checksum neutral mapping is incorrect. This problem > was being hidden since we were previously always performing checksum > offload on the translated addresses and only with IPv6 HW csum. >

Re: [PATCH] [v5] net: emac: emac gigabit ethernet controller driver

From: Timur Tabi Date: Tue, 14 Jun 2016 17:22:35 -0500 > +/* Free all descriptors of given receive queue */ > +static void emac_rx_q_free_descs(struct emac_adapter *adpt) > +{ > + struct emac_rx_queue *rx_q = >rx_q; > + struct device *dev = adpt->netdev->dev.parent;

Re: [PATCH v2 net-next] net: ipv4: Add ability to have GRE ignore DF bit in IPv4 payloads

From: "Philip Prindeville" Date: Tue, 14 Jun 2016 15:53:02 -0600 > From: Philip Prindeville > > In the presence of firewalls which improperly block ICMP Unreachable > (including Fragmentation Required) messages, Path MTU

Re: [PATCH net-next] net: vrf: Switch dst dev to loopback on device delete

From: David Ahern Date: Tue, 14 Jun 2016 11:37:21 -0700 > Attempting to delete a VRF device with a socket bound to it can stall: > > unregister_netdevice: waiting for red to become free. Usage count = 1 > > The unregister is waiting for the dst to be released and

Re: [for-next 0/1] [pull request] Mellanox ConnectX-4 Shared Code

From: Leon Romanovsky Date: Tue, 14 Jun 2016 13:29:11 +0300 > are available in the git repository at: > > g...@gitolite.kernel.org:pub/scm/linux/kernel/git/leon/linux-rdma > tags/shared You need to learn how to publish a public URL of your tree. That's your private one

Re: [net-next PATCH v2 05/17] bnxt: Update drivers to support unified UDP encapsulation offload functions

On Wed, Jun 15, 2016 at 3:07 PM, Alexander Duyck wrote: > This patch ends up doing several things. First it updates the driver to > make use of the new unified UDP tunnel offload notifier functions. In > addition I updated the code so that we can work around the bits that

linux-next: manual merge of the vhost tree with the net-next tree

Hi Michael, Today's linux-next merge of the vhost tree got a conflict in: tools/virtio/ringtest/Makefile between commit: 9fb6bc5b4a78 ("ptr_ring: ring test") from the net-next tree and commit: 139ab4d4e68b ("tools/virtio: add noring tool") from the vhost tree. I fixed it up (see

Re: [PATCH] mdio: mux: avoid 'maybe-uninitialized' warning

From: Arnd Bergmann Date: Tue, 14 Jun 2016 12:03:17 +0200 > The latest changes to the MDIO code introduced a false-positive > warning with gcc-6 (possibly others): > > drivers/net/phy/mdio-mux.c: In function 'mdio_mux_init': > drivers/net/phy/mdio-mux.c:188:3: error:

Re: [PATCHv4 net-next 00/12] 6lowpan: introduce 6lowpan-nd

From: Alexander Aring Date: Wed, 15 Jun 2016 21:20:15 +0200 > David can you please pick-up this patch-serie for your net-next tree? > Thanks in advance. Series applied to net-next, thanks.

Re: [PATCH] openvswitch: Add cutlen info to upcall.

On Wed, Jun 15, 2016 at 7:28 PM, William Tu wrote: > The commit f2a4d086ed4c ("openvswitch: Add packet truncation support.") > introduces packet truncation before sending to userspace upcall receiver. > This patch passes the number of bytes truncated in kernel to so that the >

[PATCH net 2/3] r8152: reset the bmu

Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected data remains in the hw. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c

[PATCH net 1/3] r8152: disable MAC clock speed down

Disable MAC clock speed down. It may casue the first control transfer to contain the wrong data, when the power state change from U1 to U0. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff

[PATCH net 3/3] r8152: correct the rx early size

The rx early size should be (agg_buf_sz - packet size) / 8 Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f5bc351..4e257b8

[PATCH net 0/3] r8152: fix known issues

These patches fix some known issues. Hayes Wang (3): r8152: disable MAC clock speed down r8152: reset the bmu r8152: correct the rx early size drivers/net/usb/r8152.c | 37 ++--- 1 file changed, 26 insertions(+), 11 deletions(-) -- 2.4.11

[PATCH] openvswitch: Add cutlen info to upcall.

The commit f2a4d086ed4c ("openvswitch: Add packet truncation support.") introduces packet truncation before sending to userspace upcall receiver. This patch passes the number of bytes truncated in kernel to so that the upcall receiver knows the original packet size. Potentially this will be used

[PATCH net 0/2] bpf fixes

Fixes for two bpf bugs: 1st bug reported by Sasha Goldshtein here: https://github.com/iovisor/bcc/issues/570 2nd discovered by Daniel Borkmann by manual code analysis. See patches for details. Alexei Starovoitov (2): bpf: fix matching of data/data_end in verifier bpf, trace: check event type

[PATCH net 1/2] bpf: fix matching of data/data_end in verifier

The ctx structure passed into bpf programs is different depending on bpf program type. The verifier incorrectly marked ctx->data and ctx->data_end access based on ctx offset only. That caused loads in tracing programs int bpf_prog(struct pt_regs *ctx) { .. ctx->ax .. } to be incorrectly marked as

[PATCH net 2/2] bpf, trace: check event type in bpf_perf_event_read

similar to bpf_perf_event_output() the bpf_perf_event_read() helper needs to check the type of the perf_event before reading the counter. Fixes: a43eec304259 ("bpf: introduce bpf_perf_event_output() helper") Reported-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov

RE: [Intel-wired-lan] [PATCH net v2] e1000e: keep vlan interfaces functional after rxvlan off

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jarod Wilson > Sent: Thursday, June 9, 2016 4:50 PM > To: linux-ker...@vger.kernel.org > Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: [Intel-wired-lan] [PATCH net v2] e1000e: keep

Re: [net-next PATCH v2 03/17] net: Merge VXLAN and GENEVE push notifiers into a single notifier

On Wed, Jun 15, 2016 at 3:07 PM, Alexander Duyck wrote: > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index d101e4d904ba..7f45e96967ce 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -1050,6 +1052,19 @@ struct

Re: [net-next PATCH v2 02/17] net: Combine GENEVE and VXLAN port notifiers into single functions

On Wed, Jun 15, 2016 at 3:07 PM, Alexander Duyck wrote: > diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c > index e5e33cd01082..d12ee3a92fb5 100644 > --- a/drivers/net/geneve.c > +++ b/drivers/net/geneve.c > static void geneve_notify_del_rx_port(struct geneve_sock

Re: [net-next PATCH v2 06/17] bnxt: Move GENEVE support from hard-coded port to using port notifier

On Wed, Jun 15, 2016 at 3:07 PM, Alexander Duyck wrote: > The port number for GENEVE is hard coded into the bnxt driver. This is the > kind of thing we want to avoid going forward. For now I will integrate > this back into the port notifier so that we can change the GENEVE

[iproute PATCH v2 0/2] Two cosmetic fixes in tc/m_action.c

Found these when doing something else. Shouldn't cause any functional change. Changes since v1: - Replace patch 1/2 with a better solution as suggested by Stephen Hemminger. Phil Sutter (2): tc: m_action: Use C99 style initializers for struct req tc: m_action: Drop unused variable nladdr

[iproute PATCH v2 2/2] tc: m_action: Drop unused variable nladdr in tc_action_gd()

This has been there since the introduction of tc/m_action.c back in 2004 and was apparently never in use. Signed-off-by: Phil Sutter --- tc/m_action.c | 4 1 file changed, 4 deletions(-) diff --git a/tc/m_action.c b/tc/m_action.c index f97ed2e775012..ea16817aefd4f 100644 ---

[iproute PATCH v2 1/2] tc: m_action: Use C99 style initializers for struct req

Instead of initializing fields after (or sometimes even before) zeroing the whole struct via memset(), initialize the whole thing at declaration time. Signed-off-by: Phil Sutter --- tc/m_action.c | 46 +++--- 1 file changed, 23 insertions(+),

[PATCH 2/2] net: ethernet: ax88796: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/8390/ax88796.c | 24 ++-- 1 files changed, 2 insertions(+),

[PATCH 1/2] net: ethernet: ax88796: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[net-next PATCH v2 17/17] vxlan: Add new UDP encapsulation offload type for VXLAN-GPE

The fact is VXLAN with Generic Protocol Extensions cannot be supported by the same hardware parsers that support VXLAN. The protocol extensions allow for things like a Next Protocol field which in turn allows for things other than Ethernet to be passed over the tunnel. Most existing parsers will

[net-next PATCH v2 11/17] mlx4_en: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same

[net-next PATCH v2 08/17] fm10k: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type if VXLAN we can maintain the same

[net-next PATCH v2 09/17] i40e: Move all UDP port notifiers to single function

This patch goes through and combines the notifiers for VXLAN and GENEVE into a single function for each action. So there is now one combined function for getting ports, one for adding the ports, and one for deleting the ports. Signed-off-by: Alexander Duyck ---

[net-next PATCH v2 10/17] ixgbe: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same

[net-next PATCH v2 13/17] nfp: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same

[net-next PATCH v2 15/17] qlcnic: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same

[net-next PATCH v2 16/17] net: Remove deprecated tunnel specific UDP offload functions

Now that we have all the drivers using udp_tunnel_get_rx_ports, ndo_add_udp_enc_rx_port, and ndo_del_udp_enc_rx_port we can drop the function calls that were specific to VXLAN and GENEVE. Signed-off-by: Alexander Duyck --- include/linux/netdevice.h | 38

[net-next PATCH v2 14/17] qede: Move all UDP port notifiers to single function

This patch goes through and combines the notifiers for VXLAN and GENEVE into a single function for each action. So there is now one combined function for getting ports, one for adding the ports, and one for deleting the ports. Signed-off-by: Alexander Duyck ---

[net-next PATCH v2 12/17] mlx5_en: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same

[net-next PATCH v2 05/17] bnxt: Update drivers to support unified UDP encapsulation offload functions

This patch ends up doing several things. First it updates the driver to make use of the new unified UDP tunnel offload notifier functions. In addition I updated the code so that we can work around the bits that were checking for if VXLAN was enabled since we are now using a notifier based setup.

[net-next PATCH v2 03/17] net: Merge VXLAN and GENEVE push notifiers into a single notifier

This patch merges the notifiers for VXLAN and GENEVE into a single UDP tunnel notifier. The idea is that we will want to only have to make one notifier call to receive the list of ports for VXLAN and GENEVE tunnels that need to be offloaded. In addition we add a new set of ndo functions named

[net-next PATCH v2 06/17] bnxt: Move GENEVE support from hard-coded port to using port notifier

The port number for GENEVE is hard coded into the bnxt driver. This is the kind of thing we want to avoid going forward. For now I will integrate this back into the port notifier so that we can change the GENEVE port number if we need to in the future. Signed-off-by: Alexander Duyck

[net-next PATCH v2 02/17] net: Combine GENEVE and VXLAN port notifiers into single functions

This patch merges the GENEVE and VXLAN code so that both functions pass through a shared code path. This way we can start the effort of using a single function on the network device drivers to handle both of these tunnel types. Signed-off-by: Alexander Duyck ---

[net-next PATCH v2 00/17] Future-proof tunnel offload handlers

This patch is meant to address two things. First we are currently using the ndo_add/del_vxlan_port calls with VXLAN-GPE tunnels and we cannot really support that as it is likely to cause more harm than good since VXLAN-GPE can support tunnels without a MAC address on the inner header. As such we

[net-next PATCH v2 01/17] vxlan/geneve: Include udp_tunnel.h in vxlan/geneve.h and fixup includes

This patch makes it so that we add udp_tunnel.h to vxlan.h and geneve.h header files. This is useful as I plan to move the generic handlers for the port offloads into the udp_tunnel header file and leave the vxlan and geneve headers to be a bit more protocol specific. I also went through and

[net-next PATCH v2 07/17] benet: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type if VXLAN we can maintain the same

[net-next PATCH v2 04/17] bnx2x: Move all UDP port notifiers to single function

This patch goes through and combines the notifiers for VXLAN and GENEVE into a single function for each action. So there is now one combined function for getting ports, one for adding the ports, and one for deleting the ports. I also went through and dropped the BNX2X VXLAN and GENEVE specific

Re: [PATCH net 0/3] macsec fixes

From: Sabrina Dubroca Date: Tue, 14 Jun 2016 15:25:13 +0200 > Patch 1 adds rcu_barrier() during module unload to prevent possible > panics. > > Patch 2 allocates memory for scattergather lists and the IV on the > heap, since they can escape the current function's context

Re: [PATCH net-next 0/3] Add SRIOV configuration via sysfs and few fixes

From: Hariprasad Shenai Date: Tue, 14 Jun 2016 14:39:29 +0530 > This series adds support to configure SR-IOV via PCI sysfs interface, > reduces resource allocation in kdump kernel by disabling offload. Also > synchronize unicast and multicast mac address, even in the

[PATCH v3 3/4] ipvs: Don't check result < 0 after setting result = 0

Move the block testing result < 0 to avoid the test immediately after setting result = 0 Signed-off-by: Quentin Armitage --- net/netfilter/ipvs/ip_vs_sync.c | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git

Re: [PATCH net] htb: call qdisc_root with rcu read lock held

From: Florian Westphal Date: Tue, 14 Jun 2016 06:16:27 +0200 > saw a debug splat: > net/include/net/sch_generic.h:287 suspicious rcu_dereference_check() usage! > other info that might help us debug this: > rcu_scheduler_active = 1, debug_locks = 0 > 2 locks held by

[PATCH v3 4/4] ipvs: log additional sync daemon parameters

Add new multicast parameters to log messages when sync daemons start. Commit e4ff67513096 ("ipvs: add sync_maxlen parameter for the sync daemon") and commit d33288172e72 ("ipvs: add more mcast parameters for the sync daemon") added additional multicast parameters, but didn't add them to the log

[PATCH v3 2/4] ipvs: Stop calling __dev_get_by_name() repeatedly when starting sync daemon

Optimise starting sync daemons by using the result of the first call to __dev_get_by_name() and pass the result or ifindex to subsequent functions to avoid them having to call __dev_get_by_name() again. Signed-off-by: Quentin Armitage --- net/netfilter/ipvs/ip_vs_sync.c

[PATCH v3 1/4] ipvs: Enable setting IPv6 multicast address for ipvs

When using HEAD from https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/, the command: ipvsadm --start-daemon backup --mcast-interface eth0.60 \ --mcast-group ff02::1:81 fails with the error message: Argument list too long whereas both: ipvsadm --start-daemon master

[PATCH v3 0/4] ipvs: fix backup sync daemon with IPv6, and minor updates

This series of patches arise from discovering that: ipvsadm --start-daemon backup --mcast-group IPv6_address ... would always fail. The first patch resolves the problem. The second and third patches are optimizations that were noticed while investigating the original problem. The fourth patch

[net PATCH] mlx4e: Do not attempt to offload VXLAN ports that are unrecognized

The mlx4e driver does not support more than one port for VXLAN offload. As such expecting the hardware to offload other ports is invalid since it appears the parsing logic is used to perform Tx checksum and segmentation offloads. Use the vxlan_port number to determine in which cases we can apply

Re: [PATCH] rtlwifi: use s8 instead of char

On Wednesday, June 15, 2016 5:10:51 PM CEST Jes Sorensen wrote: > > Arnd, > > rtlwifi and rtl8xxxu are two distinct drivers managed by different > people. I'd be really nice if you could split this into a per driver > patch. > > That said, the use of char in rtl8xxxu is all as a flag indicator,

[PATCH v2] rtlwifi: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited range of data type [-Werror=type-limits]

Re: [PATCH] rtlwifi: use s8 instead of char

Arnd Bergmann writes: > Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of > incorrect code that results from 'char' being unsigned here, e.g. > > realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited > range of data type

[PATCH] rtlwifi: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited range of data type [-Werror=type-limits]

Re: [PATCH net-next 00/10] net_sched: defer skb freeing while changing qdiscs

From: Eric Dumazet Date: Mon, 13 Jun 2016 20:21:49 -0700 > qdiscs/classes are changed under RTNL protection and often > while blocking BH and root qdisc spinlock. > > When lots of skbs need to be dropped, we free > them under these locks causing TX/RX freezes, > and more

Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO calculation

On Wed, Jun 15, 2016 at 1:38 PM, Eric Dumazet wrote: > > On Wed, Jun 15, 2016 at 1:34 PM, Daniel Metz wrote: > > Yuchung Cheng | 2016-06-15 20:02: > >> Let me explain in a different way: > >> > >> * RFC6298 applies a lower bound of 1 second to RTO (section

Re: [PATCH net-next 1/1] tipc: add neighbor monitoring framework

From: Jon Maloy Date: Mon, 13 Jun 2016 20:46:22 -0400 > TIPC based clusters are by default set up with full-mesh link > connectivity between all nodes. Those links are expected to provide > a short failure detection time, by default set to 1500 ms. Because > of this, the

Re: [PATCH net 1/1] net sched actions: bug fix dumping actions directly didnt produce NLMSG_DONE

From: Jamal Hadi Salim Date: Mon, 13 Jun 2016 18:08:42 -0400 > From: Jamal Hadi Salim > > This refers to commands to direct action access as follows: > > sudo tc actions add action drop index 12 > sudo tc actions add action pipe index 10 > > And then

Re: [PATCH net-next] net: vrf: Update flags and features settings

From: David Ahern Date: Mon, 13 Jun 2016 17:14:12 -0700 > 1. Default VRF devices to not having a qdisc (IFF_NO_QUEUE). Users >can add one as desired. > > 2. Disable adding a VLAN to a VRF device. > > 3. Enable offloads and hardware features similar to other

Re: [PATCH net-next] tun: fix csum generation for tap devices

From: Paolo Abeni Date: Tue, 14 Jun 2016 00:00:04 +0200 > The commit 34166093639b ("tuntap: use common code for virtio_net_hdr > and skb GSO conversion") replaced the tun code for header manipulation > with the generic helpers. While doing so, it implictly moved the >

Re: [PATCH v8 0/5] skb_array: array based FIFO for skbs

From: "Michael S. Tsirkin" Date: Mon, 13 Jun 2016 23:54:26 +0300 > This is in response to the proposal by Jason to make tun > rx packet queue lockless using a circular buffer. > My testing seems to show that at least for the common usecase > in networking, which isn't lockless,

[PATCH] bridge: netfilter: spanning tree: Add masked_ether_addr_equal and neatening

There is code duplication of a masked ethernet address comparison here so make it a separate function instead. Miscellanea: o Neaten alignment of FWINV macro uses to make it clearer for the reader Signed-off-by: Joe Perches --- This masked_ether_addr_equal function could go

Re: [PATCH 1/2] mlx5: only register devlink when ethernet is available

On Wednesday, June 15, 2016 7:04:54 PM CEST Saeed Mahameed wrote: > > Hi Arnd, > > We already took care of those issues, they only apply to Leon's tree > https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/, > this tree is meant to maintain MLX5 Shared code between netdev and >

[PATCH net-next 0/3] bpf: improve fd array release

This set improves BPF perf fd array map release wrt to purging entries, first two extend the API as needed. Please see individual patches for more details. Thanks! Daniel Borkmann (3): bpf, maps: add release callback bpf, maps: extend map_fd_get_ptr arguments bpf, maps: flush own entries

[PATCH net-next 1/3] bpf, maps: add release callback

Add a release callback for maps that is invoked when the last reference to its struct file is gone and the struct file about to be released by vfs. The handler will be used by fd array maps. Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov ---

[PATCH net-next 3/3] bpf, maps: flush own entries on perf map release

The behavior of perf event arrays are quite different from all others as they are tightly coupled to perf event fds, f.e. shown recently by commit e03e7ee34fdd ("perf/bpf: Convert perf_event_array to use struct file") to make refcounting on perf event more robust. A remaining issue that the

[PATCH net-next 2/3] bpf, maps: extend map_fd_get_ptr arguments

This patch extends map_fd_get_ptr() callback that is used by fd array maps, so that struct file pointer from the related map can be passed in. It's safe to remove map_update_elem() callback for the two maps since this is only allowed from syscall side, but not from eBPF programs for these two map

Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO calculation

Yuchung Cheng | 2016-06-15 20:02: > Let me explain in a different way: > > * RFC6298 applies a lower bound of 1 second to RTO (section 2.4) > > * Linux currently applies a lower bound of 200ms (min_rto) to > K*RTTVAR, but /not/ RTO itself. > > * This patch applies the lower bound of 200ms to RTO,

Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO calculation

On Wed, Jun 15, 2016 at 1:34 PM, Daniel Metz wrote: > Yuchung Cheng | 2016-06-15 20:02: >> Let me explain in a different way: >> >> * RFC6298 applies a lower bound of 1 second to RTO (section 2.4) >> >> * Linux currently applies a lower bound of 200ms (min_rto) to >> K*RTTVAR, but

[PATCH] net: sfc: avoid -Wtype-limits warning

When building with -Wextra, we get a harmless warning from the EFX_EXTRACT_OWORD32 macro: ethernet/sfc/farch.c: In function 'efx_farch_test_registers': ethernet/sfc/farch.c:119:30: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] ethernet/sfc/farch.c:124:144:

[PATCH] nl80211: improve nl80211_parse_mesh_config type checking

When building a kernel with W=1, the nl80211.c file causes a number of warnings, all about the same problem: net/wireless/nl80211.c: In function 'nl80211_parse_mesh_config': net/wireless/nl80211.c:5287:103: error: comparison is always false due to limited range of data type [-Werror=type-limits]

Re: [PATCH RFC 1/3] ipv4: make flow functions more grepable by removing flowi4_init_output

On 6/15/16 1:48 PM, David Miller wrote: But if people don't use the helpers, and initialize flow structures on their own, yeah that defeats the whole mechanism and things will seem harder and "unhelpful". That's my point -- the flow struct does not have a consistent initializer. There have

Re: [PATCH v2 0/5] ipvs: fix backup sync daemon with IPv6, and minor updates

Hello, On Wed, 15 Jun 2016, Quentin Armitage wrote: > I am updating the patches in line with your comments, but I'm not sure about > a couple of points. > > Patch 4: > > You state that before bind(), such changes should be safe. However, from the > function make_send_sock(), when the

Re: [PATCH RFC 1/3] ipv4: make flow functions more grepable by removing flowi4_init_output

From: David Ahern Date: Mon, 13 Jun 2016 16:02:53 -0600 > I found this helper to be unhelpful developing the VRF changes. Really > obfuscates the initialization of the flow struct. Happy to see it go. The whole point was so that it would actually be easier. If flow

Re: [Patch net-next] net_sched: make tcf_hash_check() boolean

From: Cong Wang Date: Mon, 13 Jun 2016 13:46:28 -0700 > Cc: Jamal Hadi Salim > Signed-off-by: Cong Wang Applied.

Re: [PATCH net-next 0/3] net: vrf: Handle ipv6 multicast and link-local addresses

From: David Ahern Date: Mon, 13 Jun 2016 13:44:16 -0700 > IPv6 multicast and link-local addresses require special handling by the > VRF driver. Rather than using the VRF device index and full FIB lookups, > packets to/from these addresses should use direct FIB lookups

Re: [Patch net] act_ipt: fix a bind refcnt leak

From: Cong Wang Date: Mon, 13 Jun 2016 13:44:14 -0700 > And avoid calling tcf_hash_check() twice. > > Fixes: a57f19d30b2d ("net sched: ipt action fix late binding") > Cc: Jamal Hadi Salim > Signed-off-by: Cong Wang

Re: [PATCH v2 net] net_sched: prio: insure proper transactional behavior

From: Eric Dumazet Date: Mon, 13 Jun 2016 11:33:32 -0700 > From: Eric Dumazet > > Now prio_init() can return -ENOMEM, it also has to make sure > any allocated qdiscs are freed, since the caller (qdisc_create()) wont > call ->destroy() handler for

[PATCHv4 net-next 03/12] 6lowpan: remove ipv6 module request

Since we use exported function from ipv6 kernel module we don't need to request the module anymore to have ipv6 functionality. Acked-by: Hannes Frederic Sowa Reviewed-by: Stefan Schmidt Signed-off-by: Alexander Aring ---

[PATCHv4 net-next 01/12] 6lowpan: add private neighbour data

This patch will introduce a 6lowpan neighbour private data. Like the interface private data we handle private data for generic 6lowpan and for link-layer specific 6lowpan. The current first use case if to save the short address for a 802.15.4 6lowpan neighbour. Cc: David S. Miller

[PATCHv4 net-next 10/12] 6lowpan: introduce 6lowpan-nd

This patch introduce different 6lowpan handling for receive and transmit NS/NA messages for the ipv6 neighbour discovery. The first use-case is for supporting 802.15.4 short addresses inside the option fields and handling for RFC6775 6CO option field as userspace option. Cc: David S. Miller

[PATCHv4 net-next 02/12] 6lowpan: add 802.15.4 short addr slaac

This patch adds the autoconfiguration if a valid 802.15.4 short address is available for 802.15.4 6LoWPAN interfaces. Cc: David S. Miller Cc: Alexey Kuznetsov Cc: James Morris Cc: Hideaki YOSHIFUJI Cc:

  1   2   3   >