[PATCH RFC] sparc64: eBPF JIT

There are a bunch of things I want to do still, and I know that I have to attend to sparc32 more cleanly, but I wanted to post this now that I have it passing the BPF testsuite completely: [24174.315421] test_bpf: Summary: 305 PASSED, 0 FAILED, [297/297 JIT'ed] Only major unimplemented feature

Re: ipv6 udp early demux breaks udp_l3mdev_accept=0

On 4/16/17 6:44 PM, Subash Abhinov Kasiviswanathan wrote: > Can you try this > > --- > net/ipv6/udp.c | 21 + > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c > index b793ed1..0e307e5 100644 > --- a/net/ipv6/udp.c > +++

[PATCH net 0/2] Two BPF fixes

The set fixes cb_access and xdp_adjust_head bits in struct bpf_prog, that are used for requirement checks on the program rather than f.e. heuristics. Thus, for tail calls, we cannot make any assumptions and are forced to set them. Thanks! Daniel Borkmann (2): bpf: fix cb access in socket

[PATCH net 2/2] bpf: fix checking xdp_adjust_head on tail calls

Commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog") added the xdp_adjust_head bit to the BPF prog in order to tell drivers that the program that is to be attached requires support for the XDP bpf_xdp_adjust_head() helper such that drivers not supporting this helper can reject the

[PATCH net 1/2] bpf: fix cb access in socket filter programs on tail calls

Commit ff936a04e5f2 ("bpf: fix cb access in socket filter programs") added a fix for socket filter programs such that in i) AF_PACKET the 20 bytes of skb->cb[] area gets zeroed before use in order to not leak data, and ii) socket filter programs attached to TCP/UDP sockets need to save/restore

Re: ipv6 udp early demux breaks udp_l3mdev_accept=0

Can you try this --- net/ipv6/udp.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index b793ed1..0e307e5 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -46,6 +46,7 @@ #include #include #include +#include

Re: ipv6 udp early demux breaks udp_l3mdev_accept=0

On 4/15/17 8:23 PM, Subash Abhinov Kasiviswanathan wrote: >>> It should be fixed for 4.12. Basically, __udp6_lib_demux_lookup needs to >>> be more like __udp4_lib_demux_lookup > > Hi David > > Would it be possible for you to test this with udp_l3mdev_accept=0 formatting was botched so it does

[PATCH RFC] ptr_ring: add ptr_ring_unconsume

Applications that consume a batch of entries in one go can benefit from ability to return some of them back into the ring. Add an API for that - assuming there's space. If there's no space naturally we can't do this and have to drop entries, but this implies ring is full so we'd likely drop some

Re: [PATCH nf-next] ipvs: remove unused function ip_vs_set_state_timeout

On vr, apr 14, 2017 at 02:13:09 +0200, Pablo Neira Ayuso wrote: > On Mon, Apr 10, 2017 at 03:50:44PM -0400, Aaron Conole wrote: > > There are no in-tree callers of this function and it isn't exported. > > Simon, let me know if you want to take this, or just add your > Signed-off-by. Hi Pablo, I

Re: [PATCH net-next v6 02/11] bpf,landlock: Define an eBPF program type for Landlock

On 29/03/2017 01:46, Mickaël Salaün wrote: > Add a new type of eBPF program used by Landlock rules. > > This new BPF program type will be registered with the Landlock LSM > initialization. > > Add an initial Landlock Kconfig. > > Changes since v5: > * rename file hooks.c to init.c > * fix

Re: [PATCH v3 net-next RFC] Generic XDP

On Fri, 14 Apr 2017 17:46:44 -0700 Alexei Starovoitov wrote: > But that's probably bad idea, since I was assuming that such ring > reconfiguration can be made fast, which is unlikely. > If it takes seconds to setup a ring, then drivers should just > assume

[PATCH] sh_eth: unmap DMA buffers when freeing rings

The DMA API debugging (when enabled) causes: WARNING: CPU: 0 PID: 1445 at lib/dma-debug.c:519 add_dma_entry+0xe0/0x12c DMA-API: exceeded 7 overlapping mappings of cacheline 0x01b2974d to be printed after repeated initialization of the Ether device, e.g. suspend/resume or 'ifconfig' up/down.

Re: 4.10.9 nok with realtek wlan, atom

On 04/16/2017 01:09 PM, rupert THURNER wrote: On Sun, Apr 16, 2017 at 6:02 PM, Larry Finger wrote: On 04/16/2017 05:23 AM, rupert THURNER wrote: On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger wrote: On 04/14/2017 03:26 PM, rupert

[PATCH net-next v2] bonding: deliver link-local packets with skb->dev set to link that packets arrived on

Bonding driver changes the skb->dev to the bonding-master before passing the packet to stack for further processing. This, however does not make sense for the link-local packets and it looses "the link info" once its skb->dev is changed to bonding-master. This patch changes this behavior for

Re: 4.10.9 nok with realtek wlan, atom

On Sun, Apr 16, 2017 at 6:02 PM, Larry Finger wrote: > On 04/16/2017 05:23 AM, rupert THURNER wrote: >> >> On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger >> wrote: >>> >>> On 04/14/2017 03:26 PM, rupert THURNER wrote: On Thu,

Re: [PATCH iproute2 net-next v2 1/3] ip: add ip sr command to control SR-IPv6 internal structures

Overall, this looks fine and applied. I had to add seg6.h to include/linux since it was not there. > + switch (alg_id) { > + case SEG6_HMAC_ALGO_SHA1: > + algstr = "sha1"; > + break; > + case SEG6_HMAC_ALGO_SHA256: > +

Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes

On 4/16/17, 8:03 AM, Matthias Schiffer wrote: > On 04/14/2017 07:36 PM, Stephen Hemminger wrote: >> On Fri, 14 Apr 2017 18:44:44 +0200 >> Matthias Schiffer wrote: >> >>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c >>> index 07f89b037681..95a71546e8f2

Re: [PATCH iproute2 v2] ip vrf: Add command name next to pid

On Fri, 14 Apr 2017 16:09:56 -0700 David Ahern wrote: > 'ip vrf pids' is used to list processes bound to a vrf, but it only > shows the pid leaving a lot of work for the user. Add the command > name to the output. With this patch you get the more user friendly: > >

Re: second wave of netlink extended ACK reporting

On 4/16/17 8:40 AM, Jamal Hadi Salim wrote: > > Johannes or anybody else working on it? > i.e one which sends the extack to the bowels of callees > so we can return meaningful messages > example: rtnetlink::doit() or equivalent seems to be a candidate for > taking it as a param > For things that

[PATCH net-next] net: rtnetlink: plumb extended ack to doit function

Add netlink_ext_ack arg to rtnl_doit_func. Pass extack arg to nlmsg_parse for doit functions that call it directly. This is the first step to using extended error reporting in rtnetlink. >From here individual subsystems can be updated to set netlink_ext_ack as needed. Signed-off-by: David Ahern

Re: [RFC patch 1/1] large netlink dumps

On Sun, 16 Apr 2017 09:03:08 -0400 Jamal Hadi Salim wrote: > On 17-04-15 11:08 PM, Eric Dumazet wrote: > > On Sat, 2017-04-15 at 13:07 -0400, Jamal Hadi Salim wrote: > >> Eric, > >> > >> How does attached look instead of the 32K? > >> I found it helps to let user space

Re: 4.10.9 nok with realtek wlan, atom

On 04/16/2017 05:23 AM, rupert THURNER wrote: On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger wrote: On 04/14/2017 03:26 PM, rupert THURNER wrote: On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger wrote: On 02/09/2017 01:43 PM, Bjorn Helgaas

Re: [PATCH net-next v2 6/6] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses

On 04/14/2017 07:38 PM, Stephen Hemminger wrote: > On Fri, 14 Apr 2017 18:44:46 +0200 > Matthias Schiffer wrote: > >> As link-local addresses are only valid for a single interface, we can allow >> to use the same VNI for multiple independent VXLANs, as long as the

Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes

On 04/14/2017 07:36 PM, Stephen Hemminger wrote: > On Fri, 14 Apr 2017 18:44:44 +0200 > Matthias Schiffer wrote: > >> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c >> index 07f89b037681..95a71546e8f2 100644 >> --- a/drivers/net/vxlan.c >> +++

Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes

On 04/14/2017 07:27 PM, Sergei Shtylyov wrote: > On 04/14/2017 07:44 PM, Matthias Schiffer wrote: > >> * Multicast addresses are never valid as local address >> * Link-local IPv6 unicast addresses may only be used as remote when the >> local address is link-local as well >> * Don't allow

Re: second wave of netlink extended ACK reporting

On 4/16/17 8:48 AM, Jamal Hadi Salim wrote: > Excellent. His patches seem to be in. Seems > commit ce07183282975026716107d36fd3f5f93de76668 > is a good point? yes. will send later today.

Re: second wave of netlink extended ACK reporting

On 17-04-16 10:45 AM, David Ahern wrote: On 4/16/17 8:40 AM, Jamal Hadi Salim wrote: Johannes or anybody else working on it? i.e one which sends the extack to the bowels of callees so we can return meaningful messages example: rtnetlink::doit() or equivalent seems to be a candidate for taking

Re: second wave of netlink extended ACK reporting

On 4/16/17 8:40 AM, Jamal Hadi Salim wrote: > > Johannes or anybody else working on it? > i.e one which sends the extack to the bowels of callees > so we can return meaningful messages > example: rtnetlink::doit() or equivalent seems to be a candidate for > taking it as a param I have a patch

second wave of netlink extended ACK reporting

Johannes or anybody else working on it? i.e one which sends the extack to the bowels of callees so we can return meaningful messages example: rtnetlink::doit() or equivalent seems to be a candidate for taking it as a param For things that call netlink_ack it may be easier if they create the

Re: [PATCH linux 2/2] net sched actions: fix refcount decrement on error

Wolfgang, can you _please_ stop cc-ing lkml? Everybody you need to deal with is on netdev. On 17-04-15 02:48 PM, Wolfgang Bumiller wrote: So I'm not sure exactly how the module and tc_action counts are related (and I usually like to understand my own patches ;-) ). Every time we add

Re: [PATCH net-next 1/1] net sched actions: add time filter for action dumping

I should say this is dependent on the earlier patch I posted. Made them separate because I think this one in particular may generate some discussions. cheers, jamal On 17-04-16 09:56 AM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim This adds support for filtering based

[PATCH net-next 1/1] net sched actions: add time filter for action dumping

From: Jamal Hadi Salim This adds support for filtering based on time since last used. When we are dumping a large number of actions it is useful to have the option of filtering based on when the action was last used to reduce the amount of data crossing to user space. With

Re: [RFC patch 1/1] large netlink dumps

On 17-04-15 11:08 PM, Eric Dumazet wrote: On Sat, 2017-04-15 at 13:07 -0400, Jamal Hadi Salim wrote: Eric, How does attached look instead of the 32K? I found it helps to let user space suggest something larger. cheers, jamal Looks dangerous to me, for various reasons. 1) Memory allocations

[PATCH net-next 1/1] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch

From: Jamal Hadi Salim When you dump hundreds of thousands of actions, getting only 32 per dump batch even when the socket buffer and memory allocations allow is inefficient. With this change, the user will get as many as possibly fitting within the given constraints. We

Re: [PATCH RFC ipsec-next 0/14] IPsec hardware offloding API

On Wed, Apr 12, 2017 at 08:26:39AM +0200, Steffen Klassert wrote: > This patchset adds the basic infrastructure for IPsec hardware > offloading, it creates a configuration API and adjusts the > packet path. This is now applied to ipsec-next.

[PATCH 3.18 043/145] [PATCH 093/760] net: sctp, forbid negative length

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Slaby [ Upstream commit a4b8e71b05c27bae6bad3bdecddbc6b68a3ad8cf ] Most of getsockopt handlers in net/sctp/socket.c check len against sizeof some structure like:

[PATCH net-next 1/1] ipv6: sr: fix BUG due to headroom too small after SRH push

When a locally generated packet receives an SRH with two or more segments, the remaining headroom is too small to push an ethernet header. This patch ensures that the headroom is large enough after SRH push. The BUG generated the following trace. [ 192.950285] skbuff: skb_under_panic:

Re: 4.10.9 nok with realtek wlan, atom

On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger wrote: > On 04/14/2017 03:26 PM, rupert THURNER wrote: >> >> On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger >> wrote: >>> >>> On 02/09/2017 01:43 PM, Bjorn Helgaas wrote: [+cc

[PATCH] gso: Validate assumption of frag_list segementation

From: Ilan Tayari Commit 07b26c9454a2 ("gso: Support partial splitting at the frag_list pointer") assumes that all SKBs in a frag_list (except maybe the last one) contain the same amount of GSO payload. This assumption is not always correct, resulting in the following