[PATCHv4 2/3] net: socionext: Add Synquacer NetSec driver

From: Jassi Brar This driver adds support for Socionext "netsec" IP Gigabit Ethernet + PHY IP used in the Synquacer SC2A11 SoC. Signed-off-by: Ard Biesheuvel Signed-off-by: Jassi Brar ---

[PATCHv4 3/3] MAINTAINERS: Add entry for Socionext ethernet driver

From: Jassi Brar Add entry for the Socionext Netsec controller driver and DT bindings. Acked-by: Ard Biesheuvel Signed-off-by: Jassi Brar --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff

[PATCHv4 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec

From: Jassi Brar This patch adds documentation for Device-Tree bindings for the Socionext NetSec Controller driver. Signed-off-by: Jassi Brar Signed-off-by: Ard Biesheuvel ---

[PATCHv4 0/3] Socionext Synquacer NETSEC driver

From: Jassi Brar Hi, Changes since v3 # Discard 'socionext,snq-mdio', and simply use 'mdio' subnode. # Use ioremap on ucode region as well, instead of memremap. Changes since v2 # Use 'mdio' subnode in DT bindings. # Use

Re: [bpf-next V2 PATCH 13/14] bpf: finally expose xdp_rxq_info to XDP bpf-programs

On Fri, Dec 22, 2017 at 06:12:41PM +0100, Jesper Dangaard Brouer wrote: > Now all XDP driver have been updated to setup xdp_rxq_info and assign > this to xdp_buff->rxq. Thus, it is now safe to enable access to some > of the xdp_rxq_info struct members. > > This patch extend xdp_md and expose

kasan for bpf

Hi All, the recent bugs make people question the safety of bpf and not a surprise that some folks propose to set kernel.unprivileged_bpf_disabled = 1 by default. I think it will be wrong long term decision, since it will steer bpf into "root only" mentality. The verifier checks will become

Re: [PATCH 4.9] bpf/verifier: Fix states_equal() comparison of pointer and UNKNOWN

On Sat, Dec 23, 2017 at 02:26:17AM +, Ben Hutchings wrote: > An UNKNOWN_VALUE is not supposed to be derived from a pointer, unless > pointer leaks are allowed. Therefore, states_equal() must not treat > a state with a pointer in a register as "equal" to a state with an > UNKNOWN_VALUE in that

Re: [PATCH bpf-next 1/2] bpf: fix maximum stack depth tracking logic

On Sat, Dec 23, 2017 at 03:26:27AM +0100, Jann Horn wrote: > On Sat, Dec 23, 2017 at 3:07 AM, Alexei Starovoitov > wrote: > > On Sat, Dec 23, 2017 at 02:38:29AM +0100, Jann Horn wrote: > >> On Fri, Dec 22, 2017 at 10:33 PM, Alexei Starovoitov > >>

Re: [PATCH bpf-next 1/2] bpf: fix maximum stack depth tracking logic

On Sat, Dec 23, 2017 at 3:07 AM, Alexei Starovoitov wrote: > On Sat, Dec 23, 2017 at 02:38:29AM +0100, Jann Horn wrote: >> On Fri, Dec 22, 2017 at 10:33 PM, Alexei Starovoitov wrote: >> > instead of computing max stack depth for current call chain

[PATCH 4.9] bpf/verifier: Fix states_equal() comparison of pointer and UNKNOWN

An UNKNOWN_VALUE is not supposed to be derived from a pointer, unless pointer leaks are allowed. Therefore, states_equal() must not treat a state with a pointer in a register as "equal" to a state with an UNKNOWN_VALUE in that register. This was fixed differently upstream, but the code around

Re: [PATCH bpf-next 1/2] bpf: fix maximum stack depth tracking logic

On Sat, Dec 23, 2017 at 02:38:29AM +0100, Jann Horn wrote: > On Fri, Dec 22, 2017 at 10:33 PM, Alexei Starovoitov wrote: > > instead of computing max stack depth for current call chain only > > track the maximum possible stack depth of any function at given > > frame position.

Re: [PATCH bpf-next 1/2] bpf: fix maximum stack depth tracking logic

On Fri, Dec 22, 2017 at 10:33 PM, Alexei Starovoitov wrote: > instead of computing max stack depth for current call chain only > track the maximum possible stack depth of any function at given > frame position. Such algorithm is simple and fast, but conservative, > since it

Re: [PATCH net-next] net/trace: fix printk format in inet_sock_set_state

On Sat, Dec 23, 2017 at 9:10 AM, Yafang Shao wrote: > On Sat, Dec 23, 2017 at 1:04 AM, Sergei Shtylyov > wrote: >> Hello! >> >> On 12/22/2017 06:37 PM, Yafang Shao wrote: >> >>> There's a space character missed in the printk messages. >>>

[PATCH net-next] net/trace: fix printk format in inet_sock_set_state

There's a space character missed in the printk messages. This error should be prevented with checkpatch.pl, but it couldn't caught by running with "checkpatch.pl -f .patch", that's what I had run before. What a carelessness. Fixes: 563e0bb0dc74("net: tracepoint: replace tcp_set_state

Re: [PATCH net-next] net/trace: fix printk format in inet_sock_set_state

On Sat, Dec 23, 2017 at 1:04 AM, Sergei Shtylyov wrote: > Hello! > > On 12/22/2017 06:37 PM, Yafang Shao wrote: > >> There's a space character missed in the printk messages. >> This error should be prevented with checkscript.pl, but it couldn't caught > >

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar wrote: > On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk wrote: >> IPv4 and IPv6 packets may arrive with lower-layer padding that is not >> included in the L3 length. For example, a short IPv4 packet may have

Re: thunderx sgmii interface hang

On 12/22/2017 04:22 PM, Tim Harvey wrote: On Fri, Dec 22, 2017 at 3:00 PM, David Daney wrote: On 12/22/2017 02:19 PM, Tim Harvey wrote: On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote: On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey

Re: thunderx sgmii interface hang

On Fri, Dec 22, 2017 at 3:00 PM, David Daney wrote: > On 12/22/2017 02:19 PM, Tim Harvey wrote: >> >> On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote: >>> >>> On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote: On Wed, Dec 13, 2017

Re: thunderx sgmii interface hang

On Fri, Dec 22, 2017 at 2:45 PM, Andrew Lunn wrote: >> Currently I'm not using the DP83867_PHY driver (after verifying the >> issue occurs with or without that driver). >> >> It does not occur if I limit UDP (ie 950mbps). I disabled all offloads >> and the issue still occurs. > >>

Re: [bpf-next V2 PATCH 01/14] xdp: base API for new XDP rx-queue info concept

On Fri, 22 Dec 2017 18:11:39 +0100, Jesper Dangaard Brouer wrote: > +struct xdp_rxq_info { > + struct net_device *dev; > + u32 queue_index; > + u32 reg_state; > +} cacheline_aligned; /* perf critical, avoid false-sharing */ I'm assuming this is cacheline_aligned, because of some

Re: [PATCH bpf 0/2] tools: bpftool: fix unlikely race and JSON output on error path

On 12/22/2017 08:36 PM, Jakub Kicinski wrote: > Hi! > > Two small fixes here to listing maps and programs. The loop for showing > maps is written slightly differently to programs which was missed in JSON > output support, and output would be broken if any of the system calls > failed. Second

Re: pull-request: bpf-next 2017-12-18

On 12/22/2017 03:42 PM, David Miller wrote: > From: Daniel Borkmann > Date: Fri, 22 Dec 2017 00:48:22 +0100 > >> Looks good, one thing: If I spot this correctly, isn't here a ... >> >> prog->aux->jit_data = jit_data; >> >> ... missing? Otherwise the context

[PATCH net-next 1/4] skbuff: in skb_segment, call zerocopy functions once per nskb

From: Willem de Bruijn This is a net-next follow-up to commit 268b79067942 ("skbuff: orphan frags before zerocopy clone"), which fixed a bug in net, but added a call to skb_zerocopy_clone at each frag to do so. When segmenting skbs with user frags, either the user frags must

[PATCH net-next 3/4] tcp: place all zerocopy payload in frags

From: Willem de Bruijn This avoids an unnecessary copy of 1-2KB and improves tso_fragment, which has to fall back to tcp_fragment if skb->len != skb_data_len. It also avoids a surprising inconsistency in notifications: Zerocopy packets sent over loopback have their frags

[PATCH net-next 4/4] tcp: do not allocate linear memory for zerocopy skbs

From: Willem de Bruijn Zerocopy payload is now always stored in frags, and space for headers is reversed, so this memory is unused. Signed-off-by: Willem de Bruijn --- net/ipv4/tcp.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-)

[PATCH net-next 2/4] tcp: push full zerocopy packets

From: Willem de Bruijn Skbs that reach MAX_SKB_FRAGS cannot be extended further. Do the same for zerocopy frags as non-zerocopy frags and set the PSH bit. This improves GRO assembly. Suggested-by: Eric Dumazet Signed-off-by: Willem de Bruijn

[PATCH net-next 0/4] zerocopy refinements

From: Willem de Bruijn 1/4 is a small optimization follow-up to the earlier fix to skb_segment: check skb state once per skb, instead of once per frag. 2/4 makes behavior more consistent between standard and zerocopy send: set the PSH bit when hitting MAX_SKB_FRAGS.

Re: [PATCH RFC 13/18] r8168: replace speed_down with genphy_restart_aneg

Am 22.12.2017 um 11:14 schrieb Andrew Lunn: > On Thu, Dec 21, 2017 at 09:50:39PM +0100, Heiner Kallweit wrote: >> Dealing with link partner abilities is handled by phylib, so let's >> just trigger autonegotiation here. >> >> Signed-off-by: Heiner Kallweit >> --- >>

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk wrote: > IPv4 and IPv6 packets may arrive with lower-layer padding that is not > included in the L3 length. For example, a short IPv4 packet may have > up to 6 bytes of padding following the IP payload when received on an >

Re: [PATCH RFC 12/18] r8168: switch to phy_mii_ioctl

Am 22.12.2017 um 11:00 schrieb Andrew Lunn: >> static int rtl8168_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) >> { >> -struct rtl8168_private *tp = netdev_priv(dev); >> -struct mii_ioctl_data *data = if_mii(ifr); >> +if (!netif_running(dev)) >> +return

Re: thunderx sgmii interface hang

On 12/22/2017 02:19 PM, Tim Harvey wrote: On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote: On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote: On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote: The nic appears to work fine (pings, TCP etc) up

Re: thunderx sgmii interface hang

> Currently I'm not using the DP83867_PHY driver (after verifying the > issue occurs with or without that driver). > > It does not occur if I limit UDP (ie 950mbps). I disabled all offloads > and the issue still occurs. > I'm told that the particular Cavium reference board with an SGMII phy >

Re: [PATCH v3 next-queue 08/10] ixgbe: process the Tx ipsec offload

On 12/22/2017 12:24 AM, Yanjun Zhu wrote: On 2017/12/20 8:00, Shannon Nelson wrote: If the skb has a security association referenced in the skb, then set up the Tx descriptor with the ipsec offload bits.  While we're here, we fix an oddly named field in the context descriptor struct. [...]

Re: [PATCH RFC 09/18] r8168: use genphy_soft_reset instead of open coding the soft reset

Am 22.12.2017 um 10:57 schrieb Andrew Lunn: > On Thu, Dec 21, 2017 at 09:50:28PM +0100, Heiner Kallweit wrote: >> Use genphy_soft_reset instead of open coding the soft reset. > > Hi Heiner > > At this point, you have swapped over the phylib. Does one of the > drivers in drivers/net/phy now take

Re: thunderx sgmii interface hang

On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote: > On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote: >> On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote: >> >> The nic appears to work fine (pings, TCP etc) up until a performance >> >> test is

RE: [Intel-wired-lan] [PATCH] e1000e: Fix e1000_check_for_copper_link_ich8lan return value.

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Neftin, Sasha > Sent: Wednesday, December 20, 2017 10:57 PM > To: Benjamin Poirier ; Kirsher, Jeffrey T > > Cc: Ben Hutchings ; Gabriel

[PATCH 3/3] qemu: add linkspeed and duplex settings to virtio-net

Although linkspeed and duplex can be set in a linux guest via 'ethtool -s', this requires custom ethtool commands for virtio-net by default. Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows the hypervisor to export a linkspeed and duplex setting. The user can subsequently

[PATCH 2/3] qemu: use 64-bit values for feature flags in virtio-net

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron Cc: "Michael S. Tsirkin" Cc: Jason Wang --- hw/net/virtio-net.c| 54

[PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

The ability to set speed and duplex for virtio_net in useful in various scenarios as described here: 16032be virtio_net: add ethtool support for set and get of settings However, it would be nice to be able to set this from the hypervisor, such that virtio_net doesn't require custom guest ethtool

[PATCH v2 0/3] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

We have found it useful to be able to set the linkspeed and duplex settings from the host-side for virtio_net. This obviates the need for guest changes and settings for these fields, and does not require custom ethtool commands for virtio_net.

Re: [Patch net-next] net_sched: call qdisc_reset() with qdisc lock

On Thu, Dec 21, 2017 at 7:36 PM, John Fastabend wrote: > On 12/21/2017 04:03 PM, Cong Wang wrote: >> qdisc_reset() should always be called with qdisc spinlock >> and with BH disabled, otherwise qdisc ->reset() could race >> with TX BH. >> > hmm I don't see how this fixes

[PATCH bpf-next 1/2] bpf: fix maximum stack depth tracking logic

instead of computing max stack depth for current call chain only track the maximum possible stack depth of any function at given frame position. Such algorithm is simple and fast, but conservative, since it overestimates amount of stack used. Consider: main() // stack 32 { A(); B(); } A(){}

[PATCH bpf-next 2/2] selftests/bpf: additional stack depth tests

to test inner logic of stack depth tracking Signed-off-by: Alexei Starovoitov --- tools/testing/selftests/bpf/test_verifier.c | 50 + 1 file changed, 50 insertions(+) diff --git a/tools/testing/selftests/bpf/test_verifier.c

[PATCH bpf-next 0/2] bpf: stack depth tracking fix

Jann reported an issue with stack depth tracking. Fix it and add tests. Alexei Starovoitov (2): bpf: fix maximum stack depth tracking logic selftests/bpf: additional stack depth tests include/linux/bpf_verifier.h| 17 ++ kernel/bpf/verifier.c |

Re: [PATCH v2 bpf-next 1/2] tools/bpftool: use version from the kernel source tree

On Fri, 22 Dec 2017 16:11:51 +, Roman Gushchin wrote: > Bpftool determines it's own version based on the kernel > version, which is picked from the linux/version.h header. > > It's strange to use the version of the installed kernel > headers, and makes much more sense to use the version > of

[PATCH net v2] netns, rtnetlink: fix struct net reference leak

From: Craig Gallek netns ids were added in commit 0c7aecd4bde4 and defined as signed integers in both the kernel datastructures and the netlink interface. However, the semantics of the implementation assume that the ids are always greater than or equal to zero, except for an

Re: [Patch net-next] net_sched: remove the unsafe __skb_array_empty()

On Thu, Dec 21, 2017 at 7:06 PM, John Fastabend wrote: > On 12/21/2017 04:03 PM, Cong Wang wrote: >> __skb_array_empty() is only safe if array is never resized. >> pfifo_fast_dequeue() is called in TX BH context and without >> qdisc lock, so even after we disable BH on

[PATCH net-next 0/4] kcm: Fix two locking issues

One issue is lockdep warnings when sock_owned_by_user returns true in strparser. Fix is to add and call sock_owned_by_user_nocheck since the check for owned by user is not an error condition in this case. The other issue is a potential deadlock between TX and RX paths KCM socket lock and the

[PATCH net-next 4/4] kcm: Address deadlock between TX and RX paths

Both the transmit and receive paths of KCM need to take both the KCM socket lock and the psock socket lock, however they take the locks in opposite order which can lead to deadlock. This patch changes the transmit path (kcm_write_msgs to be specific) so the locks are taken in the proper order.

[PATCH net-next 3/4] sock_lock: Add try_sock_lock

try_sock lock is an opportunistic attempt to acquire a socket lock without blocking or sleeping. If the socket lock is acquired then true is returned, else false is returned. Signed-off-by: Tom Herbert --- include/net/sock.h | 7 +++ net/core/sock.c| 20

[PATCH net-next 2/4] strparser: Call sock_owned_by_user_nocheck

strparser wants to check socket ownership without producing any warnings. As indicated by the comment in the code, it is permissible for owned_by_user to return true. Fixes: 43a0c6751a322847 ("strparser: Stream parser for messages") Reported-by: syzbot Signed-off-by:

[PATCH net-next 1/4] sock: Add sock_owned_by_user_nocheck

This allows checking socket lock ownership with producing lockdep warnings. Signed-off-by: Tom Herbert --- include/net/sock.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/net/sock.h b/include/net/sock.h index 0a32f3ce381c..3b4ca2046f8c 100644 ---

[PATCH bpf 2/2] tools: bpftool: protect against races with disappearing objects

On program/map show we may get an ID of an object from GETNEXT, but the object may disappear before we call GET_FD_BY_ID. If that happens, ignore the object and continue. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Jakub Kicinski Acked-by:

[PATCH bpf 1/2] tools: bpftool: maps: close json array on error paths of show

We can't return from the middle of do_show(), because json_array will not be closed. Break out of the loop. Note that the error handling after the loop depends on errno, so no need to set err. Fixes: 831a0aafe5c3 ("tools: bpftool: add JSON output for `bpftool map *` commands") Signed-off-by:

[PATCH bpf 0/2] tools: bpftool: fix unlikely race and JSON output on error path

Hi! Two small fixes here to listing maps and programs. The loop for showing maps is written slightly differently to programs which was missed in JSON output support, and output would be broken if any of the system calls failed. Second fix is in very unlikely case that program or map disappears

[PATCH nf-next,v3 6/7] netfilter: nf_tables: flow offload expression

Add new instruction for the nf_tables VM that allows us to specify what flows are offloaded into a given flow table via name. This new instruction creates the flow entry and adds it to the flow table. Only established flows, ie. we have seen traffic in both directions, are added to the flow

[PATCH nf-next,v3 3/7] netfilter: flow table support for IPv4

This patch adds the IPv4 flow table type, that implements the datapath flow table to forward IPv4 traffic. Rationale is: 1) Look up for the packet in the flow table, from the ingress hook. 2) If there's a hit, decrement ttl and pass it on to the neighbour layer for transmission. 3) If there's

[PATCH nf-next,v3 5/7] netfilter: flow table support for the mixed IPv4/IPv6 family

This patch adds the IPv6 flow table type, that implements the datapath flow table to forward IPv6 traffic. Signed-off-by: Pablo Neira Ayuso --- include/net/netfilter/nf_flow_table.h | 5 net/ipv4/netfilter/nf_flow_table_ipv4.c | 3 ++-

[PATCH RFC nf-next,v3 7/7] netfilter: nf_flow_table: add hardware offload support

This patch adds the infrastructure to offload flows to hardware, in case the nic/switch comes with built-in flow tables capabilities. If the hardware comes with no hardware flow tables or they have limitations in terms of features, this falls back to the software generic flow table

[PATCH nf-next,v3 4/7] netfilter: flow table support for IPv6

This patch adds the IPv6 flow table type, that implements the datapath flow table to forward IPv6 traffic. This patch exports ip6_dst_mtu_forward() that is required to check for mtu to pass up packets that need PMTUD handling to the classic forwarding path. Signed-off-by: Pablo Neira Ayuso

[PATCH nf-next,v3 2/7] netfilter: add generic flow table infrastructure

This patch defines the API to interact with flow tables, this allows to add, delete and lookup for entries in the flow table. This also adds the generic garbage code that removes entries that have expired, ie. no traffic has been seen for a while. Users of the flow table infrastructure can delete

[PATCH nf-next,v3 1/7] netfilter: nf_tables: add flow table netlink frontend

This patch introduces a netlink control plane to create, delete and dump flow tables. Flow tables are identified by name, this name is used from rules to refer to an specific flow table. Flow tables use the rhashtable class and a generic garbage collector to remove expired entries. This also adds

[PATCH nf-next,v3 0/7] Flow offload infrastructure

Hi, This is a new round of the patchset to add the flow offload infrastructure [1][2]. This round comes with IPv6 and mixed IPv4/IPv6 support, hardware offload support in a separated nf_flow_table_hw module, port translation, net namespace support and several bugfixes. Patch 7/7 has been tagged

Re: [PATCH net] rtnetlink: fix struct net reference leak

On Fri, Dec 22, 2017 at 8:59 AM, Craig Gallek wrote: > On Fri, Dec 22, 2017 at 3:11 AM, Nicolas Dichtel > wrote: >> Le 21/12/2017 à 23:18, Craig Gallek a écrit : >>> From: Craig Gallek >>> >>> The below referenced commit

Re: [PATCH] bpf: selftest for late caller stack size increase

On Fri, Dec 22, 2017 at 07:12:35PM +0100, Jann Horn wrote: > This checks that it is not possible to bypass the total stack size check in > update_stack_depth() by calling a function that uses a large amount of > stack memory *before* using a large amount of stack memory in the caller. > >

Re: INFO: task hung in bpf_exit_net

On Fri, Dec 22, 2017 at 04:28:07PM -0200, Marcelo Ricardo Leitner wrote: > On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote: > ... > > > Same with this one, perhaps related to / fixed by: > > > http://patchwork.ozlabs.org/patch/850957/ > > > > > > > > > > > Looking at the log,

Re: [PATCH v2 bpf-next 2/2] tools/bpftool: fix bpftool build with bintutils >= 2.8

Hi Roman, 2017-12-22 16:11 UTC+ ~ Roman Gushchin > Bpftool build is broken with binutils version 2.28 and later. Could you check the binutils version? I believe it changed in 2.29 instead of 2.28. Could you update your commit log and subject accordingly, please? > The cause is

Re: INFO: task hung in bpf_exit_net

On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote: ... > > Same with this one, perhaps related to / fixed by: > > http://patchwork.ozlabs.org/patch/850957/ > > > > > > Looking at the log, this one seems to be an infinite loop in SCTP code > with console output in it. Kernel is

Re: [PATCH V2 net-next 3/3] rds: tcp: cleanup if kmem_cache_alloc fails in rds_tcp_conn_alloc()

On 12/22/2017 9:39 AM, Sowmini Varadhan wrote: If kmem_cache_alloc() fails in the middle of the for() loop, cleanup anything that might have been allocated so far. Signed-off-by: Sowmini Varadhan --- v2: target net-next, not net Acked-by: Santosh Shilimkar

Re: correctness of BPF stack size checking logic for multi-function programs?

On Fri, Dec 22, 2017 at 4:37 AM, Alexei Starovoitov wrote: > On Fri, Dec 22, 2017 at 02:14:45AM +0100, Jann Horn wrote: >> Hi! >> >> I saw the recently-added support for multiple functions in a single >> program in BPF. I've stumbled over something that looks like it

[PATCH v2] sctp: Replace use of sockets_allocated with specified macro.

The patch(180d8cd942ce) replaces all uses of struct sock fields' memory_pressure, memory_allocated, sockets_allocated, and sysctl_mem to accessor macros. But the sockets_allocated field of sctp sock is not replaced at all. Then replace it now for unifying the code. Fixes: 180d8cd942ce

Re: [PATCH V2 net-next 2/3] rds: tcp: initialize t_tcp_detached to false

On 12/22/2017 9:39 AM, Sowmini Varadhan wrote: Commit f10b4cff98c6 ("rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete") adds the field t_tcp_detached, but this needs to be initialized explicitly to false. Signed-off-by: Sowmini Varadhan

Re: [PATCH V2 net-next 1/3] rds; Reset rs->rs_bound_addr in rds_add_bound() failure path

On 12/22/2017 9:38 AM, Sowmini Varadhan wrote: If the rds_sock is not added to the bind_hash_table, we must reset rs_bound_addr so that rds_remove_bound will not trip on this rds_sock. rds_add_bound() does a rds_sock_put() in this failure path, so failing to reset rs_bound_addr will result in a

Re: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO_HW

On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca wrote: > Hello, > > Sorry for commenting late. > > 2017-12-16, 03:09:39 -0500, Michael Chan wrote: >> Introduce NETIF_F_GRO_HW feature flag and convert drivers that support >> hardware GRO to use the new flag. >> >> v5: >> -

[PATCH] bpf: selftest for late caller stack size increase

This checks that it is not possible to bypass the total stack size check in update_stack_depth() by calling a function that uses a large amount of stack memory *before* using a large amount of stack memory in the caller. Currently, the first added testcase causes a rejection as expected, but the

[PATCH V2 net-next 3/3] rds: tcp: cleanup if kmem_cache_alloc fails in rds_tcp_conn_alloc()

If kmem_cache_alloc() fails in the middle of the for() loop, cleanup anything that might have been allocated so far. Signed-off-by: Sowmini Varadhan --- v2: target net-next, not net net/rds/tcp.c | 46 ++ 1 files

[PATCH V2 net-next 1/3] rds; Reset rs->rs_bound_addr in rds_add_bound() failure path

If the rds_sock is not added to the bind_hash_table, we must reset rs_bound_addr so that rds_remove_bound will not trip on this rds_sock. rds_add_bound() does a rds_sock_put() in this failure path, so failing to reset rs_bound_addr will result in a socket refcount bug, and will trigger a WARN_ON

[PATCH V2 net-next 0/3] rds bug fixes

Ran into pre-existing bugs when working on the fix for https://www.spinics.net/lists/netdev/msg472849.html The bugs fixed in this patchset are unrelated to the syzbot failure (which I'm still testing and trying to reproduce) but meanwhile, let's get these fixes out of the way. V2: target

[PATCH V2 net-next 2/3] rds: tcp: initialize t_tcp_detached to false

Commit f10b4cff98c6 ("rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete") adds the field t_tcp_detached, but this needs to be initialized explicitly to false. Signed-off-by: Sowmini Varadhan --- v2: target net-next, not net net/rds/tcp.c

Re: [PATCH v3 1/4] security: Add support for SCTP security hooks

On Fri, Dec 22, 2017 at 09:20:45AM -0800, Casey Schaufler wrote: > On 12/22/2017 5:05 AM, Marcelo Ricardo Leitner wrote: > > From: Richard Haines > > > > The SCTP security hooks are explained in: > > Documentation/security/LSM-sctp.rst Thanks Casey for your

Re: [PATCH net 2/3] rds: tcp: initialize t_tcp_detached to false

On (12/22/17 08:14), Sowmini Varadhan wrote: > Commit f10b4cff98c6 ("rds: tcp: atomically purge entries from > rds_tcp_conn_list during netns delete") adds the field t_tcp_detached, > but this needs to be initialized explicitly to false. I just realized that t_tcp_detached (and the above commit)

Re: [PATCH v3 1/4] security: Add support for SCTP security hooks

On 12/22/2017 5:05 AM, Marcelo Ricardo Leitner wrote: > From: Richard Haines > > The SCTP security hooks are explained in: > Documentation/security/LSM-sctp.rst > > Signed-off-by: Richard Haines > Acked-by: Marcelo Ricardo Leitner

[bpf-next V2 PATCH 14/14] samples/bpf: program demonstrating access to xdp_rxq_info

This sample program can be used for monitoring and reporting how many packets per sec (pps) are received per NIC RX queue index and which CPU processed the packet. In itself it is a useful tool for quickly identifying RSS imbalance issues, see below. The default XDP action is XDP_PASS in-order to

[bpf-next V2 PATCH 10/14] tun: setup xdp_rxq_info

Driver hook points for xdp_rxq_info: * reg : tun_attach * unreg: __tun_detach I've done some manual testing of this tun driver, but I would appriciate good review and someone else running their use-case tests, as I'm not 100% sure I understand the tfile->detached semantics. V2: Removed the

[bpf-next V2 PATCH 12/14] xdp: generic XDP handling of xdp_rxq_info

Hook points for xdp_rxq_info: * reg : netif_alloc_rx_queues * unreg: netif_free_rx_queues The net_device have some members (num_rx_queues + real_num_rx_queues) and data-area (dev->_rx with struct netdev_rx_queue's) that were primarily used for exporting information about RPS (CONFIG_RPS)

[bpf-next V2 PATCH 04/14] ixgbe: setup xdp_rxq_info

Driver hook points for xdp_rxq_info: * reg : ixgbe_setup_rx_resources() * unreg: ixgbe_free_rx_resources() Tested on actual hardware. V2: Fix ixgbe_set_ringparam, clear xdp_rxq_info in temp_ring Cc: intel-wired-...@lists.osuosl.org Cc: Jeff Kirsher Cc: Alexander

[bpf-next V2 PATCH 09/14] thunderx: setup xdp_rxq_info

This driver uses a bool scheme for "enable"/"disable" when setting up different resources. Thus, the hook points for xdp_rxq_info is done in the same function call nicvf_rcv_queue_config(). This is activated through enable/disable via nicvf_config_data_transfer(), which is tied into

[bpf-next V2 PATCH 11/14] virtio_net: setup xdp_rxq_info

The virtio_net driver doesn't dynamically change the RX-ring queue layout and backing pages, but instead reject XDP setup if all the conditions for XDP is not meet. Thus, the xdp_rxq_info also remains fairly static. This allow us to simply add the reg/unreg to net_device open/close functions.

[bpf-next V2 PATCH 07/14] bnxt_en: setup xdp_rxq_info

Driver hook points for xdp_rxq_info: * reg : bnxt_alloc_rx_rings * unreg: bnxt_free_rx_rings This driver should be updated to re-register when changing allocation mode of RX rings. Tested on actual hardware. Cc: Andy Gospodarek Cc: Michael Chan

[bpf-next V2 PATCH 13/14] bpf: finally expose xdp_rxq_info to XDP bpf-programs

Now all XDP driver have been updated to setup xdp_rxq_info and assign this to xdp_buff->rxq. Thus, it is now safe to enable access to some of the xdp_rxq_info struct members. This patch extend xdp_md and expose UAPI to userspace for ingress_ifindex and rx_queue_index. Access happens via bpf

[bpf-next V2 PATCH 08/14] nfp: setup xdp_rxq_info

Driver hook points for xdp_rxq_info: * reg : nfp_net_rx_ring_alloc * unreg: nfp_net_rx_ring_free In struct nfp_net_rx_ring moved member @size into a hole on 64-bit. Thus, the size remaines the same after adding member @xdp_rxq. Cc: oss-driv...@netronome.com Cc: Jakub Kicinski

[bpf-next V2 PATCH 03/14] i40e: setup xdp_rxq_info

The i40e driver have a special "FDIR" RX-ring (I40E_VSI_FDIR) which is a sideband channel for configuring/updating the flow director tables. This (i40e_vsi_)type does not invoke XDP-ebpf code. Thus, mark this type as a XDP RX-queue type RXQ_TYPE_SINK. Driver hook points for xdp_rxq_info: * reg

[bpf-next V2 PATCH 05/14] xdp/qede: setup xdp_rxq_info and intro xdp_rxq_info_is_reg

The driver code qede_free_fp_array() depend on kfree() can be called with a NULL pointer. This stems from the qede_alloc_fp_array() function which either (kz)alloc memory for fp->txq or fp->rxq. This also simplifies error handling code in case of memory allocation failures, but xdp_rxq_info_unreg

[bpf-next V2 PATCH 06/14] mlx4: setup xdp_rxq_info

Driver hook points for xdp_rxq_info: * reg : mlx4_en_create_rx_ring * unreg: mlx4_en_destroy_rx_ring Tested on actual hardware. Cc: Tariq Toukan Signed-off-by: Jesper Dangaard Brouer --- drivers/net/ethernet/mellanox/mlx4/en_netdev.c |3 ++-

[bpf-next V2 PATCH 02/14] xdp/mlx5: setup xdp_rxq_info

The mlx5 driver have a special drop-RQ queue (one per interface) that simply drops all incoming traffic. It helps driver keep other HW objects (flow steering) alive upon down/up operations. It is temporarily pointed by flow steering objects during the interface setup, and when interface is down.

[bpf-next V2 PATCH 01/14] xdp: base API for new XDP rx-queue info concept

This patch only introduce the core data structures and API functions. All XDP enabled drivers must use the API before this info can used. There is a need for XDP to know more about the RX-queue a given XDP frames have arrived on. For both the XDP bpf-prog and kernel side. Instead of extending

[bpf-next V2 PATCH 00/14] xdp: new XDP rx-queue info concept

V2: * Changed API exposed to drivers - Removed invocation of "init" in drivers, and only call "reg" (Suggested by Saeed) - Allow "reg" to fail and handle this in drivers (Suggested by David Ahern) * Removed the SINKQ qtype, instead allow to register as "unused" * Also fixed some

Re: [PATCH net-next] net/trace: fix printk format in inet_sock_set_state

Hello! On 12/22/2017 06:37 PM, Yafang Shao wrote: There's a space character missed in the printk messages. This error should be prevented with checkscript.pl, but it couldn't caught ^ be? by running with "checkscript.pl -f

[PATCH net 0/3] rds bug fixes

Ran into pre-existing bugs when working on the fix for https://www.spinics.net/lists/netdev/msg472849.html The bugs fixed in this patchset are unrelated to the syzbot failure (which I'm still testing and trying to reproduce) but meanwhile, let's get these fixes out of the way. Sowmini

Re: [QUESTION] Doubt about NAPI_GRO_CB(skb)->is_atomic in tcpv4 gro process

On Fri, Dec 22, 2017 at 12:49 AM, Yunsheng Lin wrote: > Hi, Alexander > > On 2017/12/22 0:29, Alexander Duyck wrote: >> On Thu, Dec 21, 2017 at 1:16 AM, Yunsheng Lin wrote: >>> Hi, Alexander >>> >>> On 2017/12/21 0:24, Alexander Duyck wrote:

  1   2   >