[PATCH net] drivers/net/wan/hdlc_cisco: Add hard_header_len

This driver didn't set hard_header_len. This patch sets hard_header_len for it according to its header_ops->create function. This driver's header_ops->create function (cisco_hard_header) creates a header of (struct hdlc_header), so hard_header_len should be set to sizeof(struct hdlc_header). Cc:

Re: [PATCH nf-next v3 0/3] Netfilter egress hook

Hi Lukas, On 8/27/20 10:55 AM, Lukas Wunner wrote: Introduce a netfilter egress hook to allow filtering outbound AF_PACKETs such as DHCP and to prepare for in-kernel NAT64/NAT46. Thinking more about this, how will this allow to sufficiently filter AF_PACKET? It won't. Any AF_PACKET application

Re: [PATCH] Revert "wlcore: Adding suppoprt for IGTK key in wlcore driver"

Steve deRosier writes: > On Tue, Aug 25, 2020 at 10:49 PM Mauro Carvalho Chehab > wrote: >> >> This patch causes a regression betwen Kernel 5.7 and 5.8 at wlcore: >> with it applied, WiFi stops working, and the Kernel starts printing >> this message every second: >> >>wlcore: PHY firmware ve

Re: [PATCH] Revert "wlcore: Adding suppoprt for IGTK key in wlcore driver"

Em Thu, 27 Aug 2020 13:36:28 -0700 Steve deRosier escreveu: > > > And let's revisit the discussion of having a kernel splat because an > > > unrelated piece of code fails yet the driver does exactly what it is > > > supposed to do. We shouldn't be dumping registers and stack-trace when > > > the

Re: packet deadline and process scheduling

On 8/27/20 11:45 PM, S.V.R.Anand wrote: > Hi, > > In the control loop application I am trying to build, an incoming message from > the network will have a deadline before which it should be delivered to the > receiver process. This essentially calls for a way of scheduling this process > based

[PATCH bpf-next v5 00/15] xsk: support shared umems between devices and queues

This patch set adds support to share a umem between AF_XDP sockets bound to different queue ids on the same device or even between devices. It has already been possible to do this by registering the umem multiple times, but this wastes a lot of memory. Just imagine having 10 threads each having 10

[PATCH bpf-next v5 01/15] xsk: i40e: ice: ixgbe: mlx5: pass buffer pool to driver instead of umem

Replace the explicit umem reference passed to the driver in AF_XDP zero-copy mode with the buffer pool instead. This in preparation for extending the functionality of the zero-copy mode so that umems can be shared between queues on the same netdev and also between netdevs. In this commit, only an u

[PATCH bpf-next v5 03/15] xsk: create and free buffer pool independently from umem

Create and free the buffer pool independently from the umem. Move these operations that are performed on the buffer pool from the umem create and destroy functions to new create and destroy functions just for the buffer pool. This so that in later commits we can instantiate multiple buffer pools pe

[PATCH bpf-next v5 11/15] xsk: add shared umem support between queue ids

Add support to share a umem between queue ids on the same device. This mode can be invoked with the XDP_SHARED_UMEM bind flag. Previously, sharing was only supported within the same queue id and device, and you shared one set of fill and completion rings. However, note that when sharing a umem betw

[PATCH bpf-next v5 08/15] xsk: enable sharing of dma mappings

Enable the sharing of dma mappings by moving them out from the buffer pool. Instead we put each dma mapped umem region in a list in the umem structure. If dma has already been mapped for this umem and device, it is not mapped again and the existing dma mappings are reused. Signed-off-by: Magnus Ka

[PATCH bpf-next v5 04/15] xsk: move fill and completion rings to buffer pool

Move the fill and completion rings from the umem to the buffer pool. This so that we in a later commit can share the umem between multiple HW queue ids. In this case, we need one fill and completion ring per queue id. As the buffer pool is per queue id and napi id this is a natural place for it and

[PATCH bpf-next v5 10/15] xsk: i40e: ice: ixgbe: mlx5: test for dma_need_sync earlier for better performance

Test for dma_need_sync earlier to increase performance. xsk_buff_dma_sync_for_cpu() takes an xdp_buff as parameter and from that the xsk_buff_pool reference is dug out. Perf shows that this dereference causes a lot of cache misses. But as the buffer pool is now sent down to the driver at zero-copy

[PATCH bpf-next v5 05/15] xsk: move queue_id, dev and need_wakeup to buffer pool

Move queue_id, dev, and need_wakeup from the umem to the buffer pool. This so that we in a later commit can share the umem between multiple HW queues. There is one buffer pool per dev and queue id, so these variables should belong to the buffer pool, not the umem. Need_wakeup is also something that

[PATCH bpf-next v5 02/15] xsk: i40e: ice: ixgbe: mlx5: rename xsk zero-copy driver interfaces

Rename the AF_XDP zero-copy driver interface functions to better reflect what they do after the replacement of umems with buffer pools in the previous commit. Mostly it is about replacing the umem name from the function names with xsk_buff and also have them take the a buffer pool pointer instead o

[PATCH bpf-next v5 06/15] xsk: move xsk_tx_list and its lock to buffer pool

Move the xsk_tx_list and the xsk_tx_list_lock from the umem to the buffer pool. This so that we in a later commit can share the umem between multiple HW queues. There is one xsk_tx_list per device and queue id, so it should be located in the buffer pool. Signed-off-by: Magnus Karlsson Acked-by: B

[PATCH bpf-next v5 15/15] xsk: documentation for XDP_SHARED_UMEM between queues and netdevs

Add documentation for the XDP_SHARED_UMEM feature when a UMEM is shared between different queues and/or netdevs. Signed-off-by: Magnus Karlsson Acked-by: Björn Töpel --- Documentation/networking/af_xdp.rst | 68 +++-- 1 file changed, 58 insertions(+), 10 deletion

[PATCH bpf-next v5 13/15] libbpf: support shared umems between queues and devices

Add support for shared umems between hardware queues and devices to the AF_XDP part of libbpf. This so that zero-copy can be achieved in applications that want to send and receive packets between HW queues on one device or between different devices/netdevs. In order to create sockets that share a

[PATCH bpf-next v5 09/15] xsk: rearrange internal structs for better performance

Rearrange the xdp_sock, xdp_umem and xsk_buff_pool structures so that they get smaller and align better to the cache lines. In the previous commits of this patch set, these structs have been reordered with the focus on functionality and simplicity, not performance. This patch improves throughput pe

[PATCH bpf-next v5 12/15] xsk: add shared umem support between devices

Add support to share a umem between different devices. This mode can be invoked with the XDP_SHARED_UMEM bind flag. Previously, sharing was only supported within the same device. Note that when sharing a umem between devices, just as in the case of sharing a umem between queue ids, you need to crea

[PATCH bpf-next v5 07/15] xsk: move addrs from buffer pool to umem

Replicate the addrs pointer in the buffer pool to the umem. This mapping will be the same for all buffer pools sharing the same umem. In the buffer pool we leave the addrs pointer for performance reasons. Signed-off-by: Magnus Karlsson Acked-by: Björn Töpel --- include/net/xdp_sock.h | 1 + n

[PATCH bpf-next v5 14/15] samples/bpf: add new sample xsk_fwd.c

From: Cristian Dumitrescu This sample code illustrates the packet forwarding between multiple AF_XDP sockets in multi-threading environment. All the threads and sockets are sharing a common buffer pool, with each socket having its own private buffer cache. The sockets are created with the xsk_soc

Re: [PATCH] Revert "wlcore: Adding suppoprt for IGTK key in wlcore driver"

Em Thu, 27 Aug 2020 13:36:28 -0700 Steve deRosier escreveu: > Hi Mauro, > > On Thu, Aug 27, 2020 at 10:42 AM Mauro Carvalho Chehab > wrote: > > > > Em Thu, 27 Aug 2020 08:48:30 -0700 > > Steve deRosier escreveu: > > > > > On Tue, Aug 25, 2020 at 10:49 PM Mauro Carvalho Chehab > > > wrote:

Re: packet deadline and process scheduling

There is an active Internet draft "Packet Delivery Deadline time in 6LoWPAN Routing Header" (https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/) which is presently in the RFC Editor queue and is expected to become an RFC in the near future. I happened to be one of the co-authors of this

Re: [PATCH 12/30] net: wireless: cisco: airo: Fix a myriad of coding style issues

Ondrej Zary writes: > On Thursday 27 August 2020 09:49:12 Kalle Valo wrote: >> Ondrej Zary writes: >> >> > On Monday 17 August 2020 20:27:06 Jesse Brandeburg wrote: >> >> On Mon, 17 Aug 2020 16:27:01 +0300 >> >> Kalle Valo wrote: >> >> >> >> > I was surprised to see that someone was using thi

Re: [PATCH nf-next v3 0/3] Netfilter egress hook

On 8/28/20 12:14 AM, Daniel Borkmann wrote: > Hi Lukas, > > On 8/27/20 10:55 AM, Lukas Wunner wrote: >> Introduce a netfilter egress hook to allow filtering outbound AF_PACKETs >> such as DHCP and to prepare for in-kernel NAT64/NAT46. > > Thinking more about this, how will this allow to suffic

pull-request: mac80211 2020-08-28

Hi Dave, We have a number of fixes for the current release cycle, one is for a syzbot reported warning (the sanity check) but most are more wifi protocol related. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit cf96d977381d4a23957bade2dd

Re: [PATCH 12/30] net: wireless: cisco: airo: Fix a myriad of coding style issues

On Fri, 28 Aug 2020, Kalle Valo wrote: > Ondrej Zary writes: > > > On Thursday 27 August 2020 09:49:12 Kalle Valo wrote: > >> Ondrej Zary writes: > >> > >> > On Monday 17 August 2020 20:27:06 Jesse Brandeburg wrote: > >> >> On Mon, 17 Aug 2020 16:27:01 +0300 > >> >> Kalle Valo wrote: > >> >>

pull-request: mac80211-next 2020-08-28

Hi Dave, Here also nothing stands out, though perhaps you'd be interested in the fact that we now use the new netlink range length validation for some binary attributes. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit f09665811b142cbf1eb

Re: [RFC PATCH 00/22] Enhance VHOST to enable SoC-to-SoC communication

On Thu, 9 Jul 2020 14:26:53 +0800 Jason Wang wrote: [Let me note right at the beginning that I first noted this while listening to Kishon's talk at LPC on Wednesday. I might be very confused about the background here, so let me apologize beforehand for any confusion I might spread.] > On 2020/7/

Re: [PATCH net] drivers/net/wan/hdlc_cisco: Add hard_header_len

Hello Xie, Xie He writes: > This driver didn't set hard_header_len. This patch sets hard_header_len > for it according to its header_ops->create function. BTW it's 4 bytes long: struct hdlc_header { u8 address; u8 control; __be16 protocol; }__packed; OTOH hdlc_setup_de

[PATCH net v2] net: dsa: mt7530: fix advertising unsupported 1000baseT_Half

Remove 1000baseT_Half to advertise correct hardware capability in phylink_validate() callback function. Fixes: 38f790a80560 ("net: dsa: mt7530: Add support for port 5") Signed-off-by: Landen Chao Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli --- v1->v2 - fix the commit subject spille

[PATCH net-next] net: phylink: avoid oops during initialisation

If we intend to use PCS operations, mac_pcs_get_state() will not be implemented, so will be NULL. If we also intend to register the PCS operations in mac_prepare() or mac_config(), then this leads to an attempt to call NULL function pointer during phylink_start(). Avoid this, but we must report the

Re: [PATCH net v2] net: dsa: mt7530: fix advertising unsupported 1000baseT_Half

On Fri, Aug 28, 2020 at 06:52:44PM +0800, Landen Chao wrote: > Remove 1000baseT_Half to advertise correct hardware capability in > phylink_validate() callback function. > > Fixes: 38f790a80560 ("net: dsa: mt7530: Add support for port 5") > Signed-off-by: Landen Chao > Reviewed-by: Andrew Lunn >

Re: [PATCH] net: usb: Fix uninit-was-stored issue in asix_read_phy_addr()

On Thu, Aug 27, 2020 at 1:28 PM Sergei Shtylyov wrote: > > Hello! > > On 27.08.2020 9:53, Himadri Pandya wrote: > > > The buffer size is 2 Bytes and we expect to receive the same amount of > > data. But sometimes we receive less data and run into uninit-was-stored > > issue upon read. Hence modify

Re: [PATCH RFC net-next] net/tls: Implement getsockopt SOL_TLS TLS_RX

Hello, is there any chance that this patch gets reviewed? Thanks, Yutaro 2020年8月18日(火) 23:12 Yutaro Hayakawa : > > Implement the getsockopt SOL_TLS TLS_RX which is currently missing. The > primary usecase is to use it in conjunction with TCP_REPAIR to > checkpoint/restore the TLS record layer st

[PATCH RFC] xfrm: fail to create ixgbe offload of IPsec tunnel mode sa

Based on talks and indirect references ixgbe driver does not support offloading IPsec tunnel mode. It only support transport mode. Now explicitly fail to avoid when trying to offload. Fixes: 63a67fe229ea ("ixgbe: add ipsec offload add and remove SA") Signed-off-by: Antony Antony --- I haven't tes

Re: [Patch net] net_sched: fix error path in red_init()

Cong Wang writes: > When ->init() fails, ->destroy() is called to clean up. > So it is unnecessary to clean up in red_init(), and it > would cause some refcount underflow. Hmm, yeah, qdisc_put() would get called twice. A surprising API, the init needs to make sure to always bring the qdisc int

Re: [PATCH v3 5/8] net: dsa: hellcreek: Add TAPRIO offloading support

Hi Richard, On Thu Aug 27 2020, Richard Cochran wrote: > On Tue, Aug 25, 2020 at 11:55:37AM +0200, Kurt Kanzenbach wrote: >> >> I get your point. But how to do it? We would need a timer based on the >> PTP clock in the switch. > > Can't you use an hrtimer based on CLOCK_MONOTONIC? When the switc

Re: [PATCH bpf-next] bpf: make bpf_link_info.iter similar to bpf_iter_link_info

On 8/28/20 7:19 AM, Yonghong Song wrote: bpf_link_info.iter is used by link_query to return bpf_iter_link_info to user space. Fields may be different ,e.g., map_fd vs. map_id, so we cannot reuse the exact structure. But make them similar, e.g., struct bpf_link_info { /* common fields */

Re: [PATCH 12/30] net: wireless: cisco: airo: Fix a myriad of coding style issues

Lee Jones writes: > On Fri, 28 Aug 2020, Kalle Valo wrote: > >> Ondrej Zary writes: >> >> > On Thursday 27 August 2020 09:49:12 Kalle Valo wrote: >> >> Ondrej Zary writes: >> >> >> >> > On Monday 17 August 2020 20:27:06 Jesse Brandeburg wrote: >> >> >> On Mon, 17 Aug 2020 16:27:01 +0300 >> >>

[PATCH bpf-next] samples/bpf: optimize l2fwd performance in xdpsock

Optimize the throughput performance of the l2fwd sub-app in the xdpsock sample application by removing a duplicate syscall and increasing the size of the fill ring. The latter needs some further explanation. We recommend that you set the fill ring size >= HW RX ring size + AF_XDP RX ring size. Mak

Re: pull-request: mac80211 2020-08-28

From: Johannes Berg Date: Fri, 28 Aug 2020 12:08:04 +0200 > We have a number of fixes for the current release cycle, > one is for a syzbot reported warning (the sanity check) > but most are more wifi protocol related. > > Please pull and let me know if there's any problem. Pulled, thanks Johann

Re: pull-request: mac80211-next 2020-08-28

From: Johannes Berg Date: Fri, 28 Aug 2020 12:12:37 +0200 > Here also nothing stands out, though perhaps you'd be > interested in the fact that we now use the new netlink > range length validation for some binary attributes. Awesome! > Please pull and let me know if there's any problem. Pulled

[PATCH net-next 1/2] gtp: remove useless rcu_read_lock()

The rtnl lock is taken just the line above, no need to take the rcu also. Fixes: 1788b8569f5d ("gtp: fix use-after-free in gtp_encap_destroy()") Signed-off-by: Nicolas Dichtel --- drivers/net/gtp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index c

[PATCH net-next 2/2] gtp: relax alloc constraint when adding a pdp

When a PDP context is added, the rtnl lock is held, thus no need to force a GFP_ATOMIC. Signed-off-by: Nicolas Dichtel --- drivers/net/gtp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 6f871ec31393..2ed1e82a8ad8 10064

[PATCH net-next 0/2] gtp: minor enhancements

The first patch removes a useless rcu lock and the second relax alloc constraints when a PDP context is added. drivers/net/gtp.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) Comments are welcomed, Nicolas

Re: [PATCH net-next v5 0/3] Add phylib support to smsc95xx

From: Andre Edich Date: Wed, 26 Aug 2020 13:17:14 +0200 > To allow to probe external PHY drivers, this patch series adds use of > phylib to the smsc95xx driver. ... Series applied, thank you.

Re: [PATCH] netlink: fix a data race in netlink_rcv_wake()

From: zhudi Date: Wed, 26 Aug 2020 20:01:13 +0800 > The data races were reported by KCSAN: > BUG: KCSAN: data-race in netlink_recvmsg / skb_queue_tail ... > Since the write is under sk_receive_queue->lock but the read > is done as lockless. so fix it by using skb_queue_empty_lockless() > instead

Re: [PATCHv3 next] net: add option to not create fall-back tunnels in root-ns as well

From: Mahesh Bandewar Date: Wed, 26 Aug 2020 09:05:35 -0700 > The sysctl that was added earlier by commit 79134e6ce2c ("net: do > not create fallback tunnels for non-default namespaces") to create > fall-back only in root-ns. This patch enhances that behavior to provide > option not to create fa

Re: [PATCH] net: dsa: mt7530: fix advertising unsupported

From: Landen Chao Date: Thu, 27 Aug 2020 17:15:47 +0800 > 1000baseT_Half > > Remove 1000baseT_Half to advertise correct hardware capability in > phylink_validate() callback function. > > Fixes: 38f790a80560 ("net: dsa: mt7530: Add support for port 5") > Signed-off-by: Landen Chao Applied and

[PATCH v2] netlabel: remove unused param from audit_log_format()

Commit d3b990b7f327 ("netlabel: fix problems with mapping removal") added a check to return an error if ret_val != 0, before ret_val is later used in a log message. Now it will unconditionally print "... res=1". So just drop the check. Addresses-Coverity: ("Dead code") Fixes: d3b990b7f327 ("netlab

Re: packet deadline and process scheduling

On Fri, Aug 28, 2020 at 10:51 AM S.V.R.Anand wrote: > > There is an active Internet draft "Packet Delivery Deadline time in > 6LoWPAN Routing Header" > (https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/) which > is presently in the RFC Editor queue and is expected to become an RFC in

Re: [PATCH net-next v3 0/2] Enable Fiber on DP83822 PHY

From: Dan Murphy Date: Thu, 27 Aug 2020 08:45:07 -0500 > The DP83822 Ethernet PHY has the ability to connect via a Fiber port. The > derivative PHYs DP83825 and DP83826 do not have this ability. In fiber mode > the DP83822 disables auto negotiation and has a fixed 100Mbps speed with > support fo

Re: [PATCHi v2] net: mdiobus: fix device unregistering in mdiobus_register

On Thu, Aug 27, 2020 at 10:48:48AM +0200, Heiner Kallweit wrote: > On 27.08.2020 09:06, Sascha Hauer wrote: > > After device_register has been called the device structure may not be > > freed anymore, put_device() has to be called instead. This gets violated > > when device_register() or any of the

Re: [Patch net] net_sched: fix error path in red_init()

From: Cong Wang Date: Thu, 27 Aug 2020 10:40:41 -0700 > When ->init() fails, ->destroy() is called to clean up. > So it is unnecessary to clean up in red_init(), and it > would cause some refcount underflow. > > Fixes: aee9caa03fc3 ("net: sched: sch_red: Add qevents "early_drop" and > "mark"")

RE: [PATCH net-next] Add Mellanox BlueField Gigabit Ethernet driver

> > + The second generation BlueField SoC from Mellanox Technologies > > + supports an out-of-band Gigabit Ethernet management port to the > > + Arm subsystem. > > You might want to additionally select the PHY driver you are using. > It is preferable to not set a specific PHY driver h

RE: [PATCH net-next] Add Mellanox BlueField Gigabit Ethernet driver

> > +static int mlxbf_gige_get_link_ksettings(struct net_device *netdev, > > +struct ethtool_link_ksettings > *link_ksettings) { > > + struct phy_device *phydev = netdev->phydev; > > + u32 supported, advertising; > phy_ethtool_ksettings_get() and maybe phy_e

Re: [PATCH net-next] Add Mellanox BlueField Gigabit Ethernet driver

On Fri, Aug 28, 2020 at 02:24:28PM +, Asmaa Mnebhi wrote: > > > + The second generation BlueField SoC from Mellanox Technologies > > > + supports an out-of-band Gigabit Ethernet management port to the > > > + Arm subsystem. > > > > You might want to additionally select the PHY driver you

Re: [PATCH v2] netlabel: remove unused param from audit_log_format()

On Fri, Aug 28, 2020 at 9:56 AM Alex Dewar wrote: > > Commit d3b990b7f327 ("netlabel: fix problems with mapping removal") > added a check to return an error if ret_val != 0, before ret_val is > later used in a log message. Now it will unconditionally print "... > res=1". So just drop the check. >

[PATCH iproute2-next] ip xfrm: support printing XFRMA_SET_MARK_MASK attribute in states

The XFRMA_SET_MARK_MASK attribute is set in states (4.19+). It is the mask of XFRMA_SET_MARK(a.k.a. XFRMA_OUTPUT_MARK in 4.18) sample output: note the output-mark mask ip xfrm state src 192.1.2.23 dst 192.1.3.33 proto esp spi 0xSPISPI reqid REQID mode tunnel replay-window 3

Re: [PATCH v3 net-next 00/12] ionic memory usage rework

From: Shannon Nelson Date: Thu, 27 Aug 2020 16:00:18 -0700 > Previous review comments have suggested [1],[2] that this driver > needs to rework how queue resources are managed and reconfigured > so that we don't do a full driver reset and to better handle > potential allocation failures. This pa

Re: [PATCH] Remove ipvs v6 dependency on iptables

Le 28/08/2020 à 00:07, Lach a écrit : > This dependency was added in 63dca2c0b0e7a92cb39d1b1ecefa32ffda201975, > because this commit had dependency on > ipv6_find_hdr, which was located in iptables-specific code > > But it is no longer required, because > f8f626754ebeca613cf1af2e6f890cfde0e74d5b

Re: linux-next: build failure after merge of the net-next tree

On 2020-08-27 11:12 -0700, Brian Vazquez wrote: > I've been trying to reproduce it with your config but I didn't > succeed. I also looked at the file after the preprocessor and it > looked good: > > ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ? > fib6_rule_match(rule, fl, flags

Re: linux-next: build failure after merge of the net-next tree

On 8/28/20 8:09 AM, Sven Joachim wrote: > On 2020-08-27 11:12 -0700, Brian Vazquez wrote: > >> I've been trying to reproduce it with your config but I didn't >> succeed. I also looked at the file after the preprocessor and it >> looked good: >> >> ret = ({ __builtin_expect(!!(ops->match == fib6_ru

[PATCH net-next v2 0/2] Add ip6_fragment in ipv6_stub

From: wenxu Add ip6_fragment in ipv6_stub and use it in openvswitch This version add default function eafnosupport_ipv6_fragment wenxu (2): ipv6: add ipv6_fragment hook in ipv6_stub openvswitch: using ip6_fragment in ipv6_stub include/net/ipv6_stubs.h | 3 +++ net/ipv6/addrconf_core.c |

[PATCH net-next v2 1/2] ipv6: add ipv6_fragment hook in ipv6_stub

From: wenxu Add ipv6_fragment to ipv6_stub to avoid calling netfilter when access ip6_fragment. Signed-off-by: wenxu --- v2: add default one eafnosupport_ipv6_fragment include/net/ipv6_stubs.h | 3 +++ net/ipv6/addrconf_core.c | 8 net/ipv6/af_inet6.c | 1 + 3 files changed, 12

[PATCH net-next v2 2/2] openvswitch: using ip6_fragment in ipv6_stub

From: wenxu Using ipv6_stub->ipv6_fragment to avoid the netfilter dependency Signed-off-by: wenxu --- net/openvswitch/actions.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c index 2611657..fd34089 100644 --- a/ne

[PATCH bpf-next] 0001-samples-bpf-fix-to-xdpsock-to-avoid-recycling-frames.patch

--- ...to-xdpsock-to-avoid-recycling-frames.patch | 62 +++ 1 file changed, 62 insertions(+) create mode 100644 0001-samples-bpf-fix-to-xdpsock-to-avoid-recycling-frames.patch diff --git a/0001-samples-bpf-fix-to-xdpsock-to-avoid-recycling-frames.patch b/0001-samples-bpf-fix-to

Re: [PATCH v3 bpf-next 0/3] bpf: Relax the max_entries check for inner map

On 8/28/20 3:18 AM, Martin KaFai Lau wrote: v3: - Add map_meta_equal to bpf_map_ops and use it as an explict opt-in support for map-in-map v2: - New BPF_MAP_TYPE_FL to minimize code churns (Alexei) - s/capabilities/properties/ (Andrii) - Describe WHY in commit log (Andrii) People has a u

[PATCH net] cxgb4: fix thermal zone device registration

When multiple adapters are present in the system, pci hot-removing second adapter leads to the following warning as both the adapters registered thermal zone device with same thermal zone name/type. Therefore, use unique thermal zone name during thermal zone device initialization. Also mark thermal

Re: VRRP not working on i40e X722 S2600WFT

On Thu, Aug 27, 2020 at 02:30:39PM -0400, Lennart Sorensen wrote: > I have hit a new problem with the X722 chipset (Intel R1304WFT server). > VRRP simply does not work. > > When keepalived registers a vmac interface, and starts transmitting > multicast packets with the vrp message, it never receiv

Re: [PATCH v2] netlabel: remove unused param from audit_log_format()

From: Alex Dewar Date: Fri, 28 Aug 2020 14:55:23 +0100 > Commit d3b990b7f327 ("netlabel: fix problems with mapping removal") > added a check to return an error if ret_val != 0, before ret_val is > later used in a log message. Now it will unconditionally print "... > res=1". So just drop the check

RE: [PATCH bpf-next] 0001-samples-bpf-fix-to-xdpsock-to-avoid-recycling-frames.patch

> -Original Message- > From: Janjua, Weqaar A > Sent: Friday, August 28, 2020 4:20 PM > To: Karlsson, Magnus ; Topel, Bjorn > ; a...@kernel.org; dan...@iogearbox.net; > netdev@vger.kernel.org; jonathan.le...@gmail.com > Cc: Janjua, Weqaar A ; b...@vger.kernel.org > Subject: [PATCH bpf-next

[PATCH bpf-next] samples/bpf: fix to xdpsock to avoid recycling frames

The txpush program in the xdpsock sample application is supposed to send out all packets in the umem in a round-robin fashion. The problem is that it only cycled through the first BATCH_SIZE worth of packets. Fixed this so that it cycles through all buffers in the umem as intended. Fixes: 248c7f9c

Re: [PATCH] net: netfilter: delete repeated words

On Sat, Aug 22, 2020 at 06:07:27PM -0700, Randy Dunlap wrote: > Drop duplicated words in net/netfilter/ and net/ipv4/netfilter/. Applied, thanks.

Re: [PATCH V2 1/5 nf] selftests: netfilter: fix header example

On Sun, Aug 23, 2020 at 08:15:37PM +0200, Fabian Frederick wrote: > nft_flowtable.sh is made for bash not sh. > Also give values which not return "RTNETLINK answers: Invalid > argument" Series from 1 to 5 is applied.

Re: [PATCH v3 1/1] netfilter: nat: add a range check for l3/l4 protonum

Hi Will, Given this is for -stable maintainers only, I'd suggest: 1) Specify what -stable kernel versions this patch applies to. Explain that this problem is gone since what kernel version. 2) Maybe clarify that this is only for stable in the patch subject, e.g. [PATCH -stable v3] netfilte

Re: [PATCH net-next 2/3] devlink: Consider other controller while building phys_port_name

On Fri, 28 Aug 2020 04:27:19 + Parav Pandit wrote: > > From: Jakub Kicinski > > Sent: Friday, August 28, 2020 3:12 AM > > > > On Thu, 27 Aug 2020 20:15:01 + Parav Pandit wrote: > > > > From: Jakub Kicinski > > > > > > > > I find it strange that you have pfnum 0 everywhere but then > >

Re: [PATCH v3 1/1] netfilter: nat: add a range check for l3/l4 protonum

Pablo Neira Ayuso wrote: > Hi Will, > > Given this is for -stable maintainers only, I'd suggest: > > 1) Specify what -stable kernel versions this patch applies to. >Explain that this problem is gone since what kernel version. > > 2) Maybe clarify that this is only for stable in the patch su

Re: [PATCH RFC net-next] net/tls: Implement getsockopt SOL_TLS TLS_RX

On Tue, 18 Aug 2020 14:12:24 + Yutaro Hayakawa wrote: > @@ -352,7 +352,11 @@ static int do_tls_getsockopt_tx(struct sock *sk, char > __user *optval, > } > > /* get user crypto info */ > - crypto_info = &ctx->crypto_send.info; > + if (tx) { > + crypto_info = &

Re: [PATCH v3 1/1] netfilter: nat: add a range check for l3/l4 protonum

On Fri, Aug 28, 2020 at 06:45:51PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso wrote: > > Hi Will, > > > > Given this is for -stable maintainers only, I'd suggest: > > > > 1) Specify what -stable kernel versions this patch applies to. > >Explain that this problem is gone since what ke

Re: [PATCH net-next v1 3/3] hinic: add support to query function table

On Fri, 28 Aug 2020 11:16:22 +0800 luobin (L) wrote: > On 2020/8/28 3:44, Jakub Kicinski wrote: > > On Thu, 27 Aug 2020 19:13:21 +0800 Luo bin wrote: > >> + switch (idx) { > >> + case VALID: > >> + return funcfg_table_elem->dw0.bs.valid; > >> + case RX_MODE: > >> + return fun

Re: [Linux-kernel-mentees] [PATCH net-next v2] ipvs: Fix uninit-value in do_ip_vs_set_ctl()

On Tue, Aug 11, 2020 at 03:46:40AM -0400, Peilin Ye wrote: > do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is > zero. Fix it. Applied to nf-next, thanks.

[PATCH net-next 0/4] sfc: clean up some W=1 build warnings

A collection of minor fixes to issues flagged up by W=1. After this series, the only remaining warnings in the sfc driver are some 'member missing in kerneldoc' warnings from ptp.c. Tested by building on x86_64 and running 'ethtool -p' on an EF10 NIC; there was no error, but I couldn't observe th

[PATCH net-next 1/4] sfc: fix W=1 warnings in efx_farch_handle_rx_not_ok

Some of these RX-event flags aren't used at all, so remove them. Others are used only #ifdef DEBUG to log a message; suppress the unused-var warnings #ifndef DEBUG with a void cast. Signed-off-by: Edward Cree --- drivers/net/ethernet/sfc/farch.c | 7 ++- 1 file changed, 2 insertions(+), 5 d

[PATCH net-next 2/4] sfc: fix unused-but-set-variable warning in efx_farch_filter_remove_safe

Thanks to some past refactor, 'spec' is not actually used in this function; the code using it moved to the callee efx_farch_filter_remove. Remove the variable to fix a W=1 warning. Signed-off-by: Edward Cree --- drivers/net/ethernet/sfc/farch.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH net-next 4/4] sfc: return errors from efx_mcdi_set_id_led, and de-indirect

W=1 warnings indicated that 'rc' was unused in efx_mcdi_set_id_led(); change the function to return int instead of void and plumb the rc through the caller efx_ethtool_phys_id(). Since (post-Falcon) all sfc NICs use MCDI for this, there's no point in indirecting through a nic_type method, so rem

[PATCH net-next 3/4] sfc: fix kernel-doc on struct efx_loopback_state

Missing 'struct' keyword caused "cannot understand function prototype" warnings. Signed-off-by: Edward Cree --- drivers/net/ethernet/sfc/selftest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/sfc/selftest.c b/drivers/net/ethernet/sfc/selftest.c inde

Re: [PATCH net-next] netfilter: xt_HMARK: Use ip_is_fragment() helper

On Thu, Aug 27, 2020 at 10:08:13PM +0800, YueHaibing wrote: > Use ip_is_fragment() to simpify code. Applied.

Re: [PATCH] netfilter: nf_conntrack_sip: fix parsing error

On Sat, Aug 15, 2020 at 12:50:30PM -0400, Tong Zhang wrote: > ct_sip_parse_numerical_param can only return 0 or 1, but the caller is > checking parsing error using < 0 Is this are real issue in your setup or probably some static analysis tool is reporting? You are right that ct_sip_parse_numerica

Re: [PATCH] netfilter: nf_conntrack_sip: fix parsing error

Hi Pablo, I'm not an expert in this networking stuff. But from my point of view there's no point in checking if this condition is always true. There's also no need of returning anything from the ct_sip_parse_numerical_param() if they are all being ignored like this. On Fri, Aug 28, 2020 at 2:07 PM

Re: [PATCH net-next] net/sched: add act_ct_output support

On Tue, Aug 25, 2020 at 8:33 AM Marcelo Ricardo Leitner wrote: > I still don't understand Cong's argument for not having this on > act_mirred because TC is L2. That's actually not right. TC hooks at L2 You miss a very important point that it is already too late to rename act_mirred to reflect wha

Re: [PATCH] netfilter: nf_conntrack_sip: fix parsing error

On Fri, Aug 28, 2020 at 02:14:48PM -0400, Tong Zhang wrote: > Hi Pablo, > I'm not an expert in this networking stuff. > But from my point of view there's no point in checking if this > condition is always true. Understood. > There's also no need of returning anything from the > ct_sip_parse_numer

Re: [PATCH v3 00/11] Fix PM hibernation in Xen guests

On Fri, Aug 21, 2020 at 10:22:43PM +, Anchal Agarwal wrote: > Hello, > This series fixes PM hibernation for hvm guests running on xen hypervisor. > The running guest could now be hibernated and resumed successfully at a > later time. The fixes for PM hibernation are added to block and > network

Re: [PATCH v3 00/11] Fix PM hibernation in Xen guests

On Fri, Aug 28, 2020 at 8:26 PM Anchal Agarwal wrote: > > On Fri, Aug 21, 2020 at 10:22:43PM +, Anchal Agarwal wrote: > > Hello, > > This series fixes PM hibernation for hvm guests running on xen hypervisor. > > The running guest could now be hibernated and resumed successfully at a > > later

Re: [PATCH] netfilter: nf_conntrack_sip: fix parsing error

I think the original code complaining parsing error is there for a reason, A better way is to modify ct_sip_parse_numerical_param() and let it return a real parsing error code instead of returning FOUND(1) and NOT FOUND(0) if deemed necessary Once again I'm not an expert and I'm may suggest somethi

Re: [PATCH net-next] net/sched: add act_ct_output support

On Tue, Aug 25, 2020 at 1:45 AM wrote: > > From: wenxu > > The fragment packets do defrag in act_ct module. If the reassembled > packet should send out to another net device. This over mtu big packet > should be fragmented to send out. This patch add the act ct_output to > archive this. There ar

Re: [PATCH v3 00/11] Fix PM hibernation in Xen guests

On Fri, Aug 28, 2020 at 08:29:24PM +0200, Rafael J. Wysocki wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > On Fri, Aug 28, 2020 at 8:26 PM Anchal Agarwa

RE: [PATCH nf-next v3 3/3] netfilter: Introduce egress hook

Lukas Wunner wrote: > Commit e687ad60af09 ("netfilter: add netfilter ingress hook after > handle_ing() under unique static key") introduced the ability to > classify packets on ingress. > > Support the same on egress. This allows filtering locally generated > traffic such as DHCP, or outbound AF_

Re: [PATCHi v2] net: mdiobus: fix device unregistering in mdiobus_register

On 28.08.2020 16:15, Sascha Hauer wrote: > On Thu, Aug 27, 2020 at 10:48:48AM +0200, Heiner Kallweit wrote: >> On 27.08.2020 09:06, Sascha Hauer wrote: >>> After device_register has been called the device structure may not be >>> freed anymore, put_device() has to be called instead. This gets viola

  1   2   >