Re: [GIT PULL net-next] rxrpc: Improve conn/call lookup and fix call number generation [ver #3]

David Miller wrote: > I'll pull, but this is not how I want you to operate. Anyway, thanks for pulling it. David

DHCP via bridge in case of IPv4

Hello, I was playing with quite simple bridged setup on different boards with very recent kernels (4.6.3 as of this writing) and found one interesting behavior that I cannot yet understand and googling din't help here as well. My setup is pretty simple: -   -- 

[PATCH net] ipv4: reject RTNH_F_LINKDOWN for incompatible routes

Vegard Nossum is reporting for a crash in fib_dump_info (fib_nhs==1) when nh_dev = NULL. Problem happens when RTNH_F_LINKDOWN is provided from user space for routes that do not use the flag, catched with netlink fuzzer. RTNH_F_LINKDOWN should be used only for link routes, not for local routes or

Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

Shmulik Ladkani wrote: [ CC > On Tue, 5 Jul 2016 15:03:27 +0200, f...@strlen.de wrote: > > > The expected behavior in such a setup would be segmenting the skb first, > > > and then fragmenting each segment according to dst mtu, and finally > > > passing the

Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

David Miller wrote: > From: Shmulik Ladkani > Date: Tue, 5 Jul 2016 17:05:41 +0300 > > > On Tue, 5 Jul 2016 15:03:27 +0200, f...@strlen.de wrote: > >> (Or did I misunderstand this setup...?) > > > > tap0 bridged with vxlan0. > > route to

Re: XDP seeking input from NIC hardware vendors

On Fri, 8 Jul 2016 18:51:07 +0100 Jakub Kicinski wrote: > On Fri, 8 Jul 2016 09:45:25 -0700, John Fastabend wrote: > > The only distinction between VFs and queue groupings on my side is VFs > > provide RSS where as queue groupings have to be selected explicitly. > >

Re: [PATCH net-next 0/6] sctp: implement rfc7496 in sctp

On Sat, Jul 9, 2016 at 7:47 PM, Xin Long wrote: > This patchset implements "Additional Policies for the Partially Reliable > Stream Control Transmission Protocol Extension" described on RFC7496. > > The Partially Reliable SCTP (PR-SCTP) extension defined in [RFC3758] >

Re: [LEDE-DEV] DHCP via bridge in case of IPv4

Hi Aaron, On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > wrote: > > > > Hello, > > > > I was playing with quite simple bridged setup on different boards with > > very recent kernels (4.6.3 as of this writing)

Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

On Sat, 9 Jul 2016 11:00:20 +0200 Florian Westphal wrote: > Shmulik Ladkani wrote: > > > How does work if e.g. 1460-sized udp packet arrives on tap0? > > > Do we fragment (possibly ignoring DF?) > > > > A *non* gso udp packet arriving on

Re: [PATCH v6 01/12] bpf: add XDP prog type for early driver filter

On Thu, 7 Jul 2016 19:15:13 -0700 Brenden Blanco wrote: > Add a new bpf prog type that is intended to run in early stages of the > packet rx path. Only minimal packet metadata will be available, hence a > new context type, struct xdp_md, is exposed to userspace. So far

Re: [PATCH net] tcp: make challenge acks less predictable

On Fri, 2016-07-08 at 17:27 -0700, Yue Cao wrote: > Hi Eric, > > > Thank you for the email. After rethinking the suggested patch, our > side-channel attack might still work. > > > The main idea behind the patch is to change challenge_count lifetime > from 1s to a random value in the range

Re: [PATCH net] udp: prevent bugcheck if filter truncates packet too much

On 07/09/2016 02:20 AM, Alexei Starovoitov wrote: On Sat, Jul 09, 2016 at 01:31:40AM +0200, Eric Dumazet wrote: On Fri, 2016-07-08 at 17:52 +0200, Michal Kubecek wrote: If socket filter truncates an udp packet below the length of UDP header in udpv6_queue_rcv_skb() or udp_queue_rcv_skb(), it

Re: [GIT PULL net-next] rxrpc: Improve conn/call lookup and fix call number generation [ver #3]

David Miller wrote: > > Can you pull this into net-next please? > > I'll pull, but this is not how I want you to operate. > > If you change stuff, you must repost the entire series. And this is > one of many reasons I want people to keep patch sets small, so that > this

[iproute PATCH 6/6] ip-link.8: Fix font choices

Signed-off-by: Phil Sutter --- man/man8/ip-link.8.in | 92 ++- 1 file changed, 47 insertions(+), 45 deletions(-) diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in index ada20fe210793..1644af0ef9f9f 100644 ---

[iproute PATCH 1/6] iplink: List valid 'type' argument in ip link help text

Signed-off-by: Phil Sutter --- ip/iplink.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ip/iplink.c b/ip/iplink.c index f2a2e13cf0c5b..0e3cee6af8b6f 100644 --- a/ip/iplink.c +++ b/ip/iplink.c @@ -55,7 +55,9 @@ void iplink_usage(void)

[iproute PATCH 5/6] ip-link.8: Add slave type option descriptions

Signed-off-by: Phil Sutter --- man/man8/ip-link.8.in | 129 ++ 1 file changed, 129 insertions(+) diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in index 2678d37df7478..ada20fe210793 100644 --- a/man/man8/ip-link.8.in +++

[iproute PATCH 0/6] iplink: Improve documentation

This series improves documentation around the feature of 'ip link set' to configure device type specific parameters. While doing so, I reviewed used fonts in ip-link.8 and fixed a few bugs/inconsistencies. Phil Sutter (6): iplink: List valid 'type' argument in ip link help text iplink:

[iproute PATCH 4/6] ip-link.8: Place 'ip link set' warning more prominently

This moves the warning to the beginning of the section about 'ip link set' which makes it still stand out after adding more text to it's end. Signed-off-by: Phil Sutter --- man/man8/ip-link.8.in | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff

[iproute PATCH 3/6] ip-link.8: Extend type list in synopsis

'ip link set' supports passing a type to set type-specific parameters. Add this missing piece of information to the synopsis section. Signed-off-by: Phil Sutter --- man/man8/ip-link.8.in | 71 +-- 1 file changed, 40 insertions(+), 31

[iproute PATCH 2/6] iplink: bond_slave: Add missing help functions

Signed-off-by: Phil Sutter --- ip/iplink_bond_slave.c | 24 1 file changed, 24 insertions(+) diff --git a/ip/iplink_bond_slave.c b/ip/iplink_bond_slave.c index d67793237edfc..9c60dea8a2757 100644 --- a/ip/iplink_bond_slave.c +++ b/ip/iplink_bond_slave.c @@

[iproute PATCH] ip-address.8: Document autojoin flag

Description copied from related kernel support commit message with a little tailoring to fit. While at it, fix font of non-terminal CONFFLAG-LIST in synopsis. Signed-off-by: Phil Sutter --- man/man8/ip-address.8.in | 21 +++-- 1 file changed, 19 insertions(+), 2

Re: [PATCH net] udp: prevent bugcheck if filter truncates packet too much

On Sat, Jul 09, 2016 at 11:48:49AM +0200, Daniel Borkmann wrote: > On 07/09/2016 02:20 AM, Alexei Starovoitov wrote: > >On Sat, Jul 09, 2016 at 01:31:40AM +0200, Eric Dumazet wrote: > >>On Fri, 2016-07-08 at 17:52 +0200, Michal Kubecek wrote: > >>>If socket filter truncates an udp packet below the

[PATCH net-next 2/6] sctp: add SCTP_DEFAULT_PRINFO into sctp sockopt

This patch adds SCTP_DEFAULT_PRINFO to sctp sockopt. It is used to set/get sctp Partially Reliable Policies' default params, which includes 3 policies (ttl, rtx, prio) and their values. Still, if we set policy params in sndinfo, we will use the params of sndinfo against chunks, instead of the

[PATCH net-next 6/6] sctp: implement prsctp PRIO policy

prsctp PRIO policy is a policy to abandon lower priority chunks when asoc doesn't have enough snd buffer, so that the current chunk with higher priority can be queued successfully. Similar to TTL/RTX policy, we will set the priority of the chunk to prsctp_param with sinfo->sinfo_timetolive in

[PATCH net-next 3/6] sctp: add SCTP_PR_ASSOC_STATUS on sctp sockopt

This patch adds SCTP_PR_ASSOC_STATUS to sctp sockopt, which is used to dump the prsctp statistics info from the asoc. The prsctp statistics includes abandoned_sent/unsent from the asoc. abandoned_sent is the count of the packets we drop packets from retransmit/transmited queue, and

[PATCH net-next 5/6] sctp: implement prsctp RTX policy

prsctp RTX policy is a policy to abandon chunks when they are retransmitted beyond the max count. This patch uses sent_count to count how many times one chunk has been sent, and prsctp_param is the max rtx count, which is from sinfo->sinfo_timetolive in sctp_set_prsctp_policy(). So similar to TTL

[PATCH net-next 4/6] sctp: implement prsctp TTL policy

prsctp TTL policy is a policy to abandon chunks when they expire at the specific time in local stack. It's similar with expires_at in struct sctp_datamsg. This patch uses sinfo->sinfo_timetolive to set the specific time for TTL policy. sinfo->sinfo_timetolive is also used for msg->expires_at. So

Re: [LEDE-DEV] DHCP via bridge in case of IPv4

On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin wrote: > Hello, > > I was playing with quite simple bridged setup on different boards with > very recent kernels (4.6.3 as of this writing) and found one interesting > behavior that I cannot yet understand and googling

[PATCH net-next 0/6] sctp: implement rfc7496 in sctp

This patchset implements "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension" described on RFC7496. The Partially Reliable SCTP (PR-SCTP) extension defined in [RFC3758] provides a generic method for senders to abandon user messages. The decision to

[PATCH net-next 1/6] sctp: add SCTP_PR_SUPPORTED on sctp sockopt

According to section 4.5 of rfc7496, prsctp_enable should be per asoc. We will add prsctp_enable to both asoc and ep, and replace the places where it used net.sctp->prsctp_enable with asoc->prsctp_enable. ep->prsctp_enable will be initialized with net.sctp->prsctp_enable, and asoc->prsctp_enable

HI Dear.

Hi Dear, I'm Amal Isabelle; I am a National of France and I live in Abidjan, Cote d’Ivoire. I’m contacting because I want to be your friend and confide in you because I have in my possession now 186.13 Kilograms of Gold Dust, Quality: 23 carat, purity 92% that I inherited from my late mother

Re: [PATCH net] ipv4: reject RTNH_F_LINKDOWN for incompatible routes

On 07/09/2016 07:23 PM, Andy Gospodarek wrote: On Sat, Jul 09, 2016 at 12:00:15PM +0300, Julian Anastasov wrote: Vegard Nossum is reporting for a crash in fib_dump_info (fib_nhs==1) when nh_dev = NULL. Problem happens when RTNH_F_LINKDOWN is provided from user space for routes that do not use

Re: [PATCH net] ipv4: reject RTNH_F_LINKDOWN for incompatible routes

On Sat, Jul 09, 2016 at 12:00:15PM +0300, Julian Anastasov wrote: > Vegard Nossum is reporting for a crash in fib_dump_info (fib_nhs==1) > when nh_dev = NULL. Problem happens when RTNH_F_LINKDOWN is > provided from user space for routes that do not use the flag, > catched with netlink fuzzer. Can

Re: [PATCH v6 05/12] Add sample for adding simple drop program to link

On Fri, Jul 8, 2016 at 5:15 AM, Brenden Blanco wrote: > Add a sample program that only drops packets at the BPF_PROG_TYPE_XDP_RX > hook of a link. With the drop-only program, observed single core rate is > ~20Mpps. > > Other tests were run, for instance without the dropcnt

Re: [PATCH net] ipv4: reject RTNH_F_LINKDOWN for incompatible routes

Hello, On Sat, 9 Jul 2016, Andy Gospodarek wrote: > On Sat, Jul 09, 2016 at 12:00:15PM +0300, Julian Anastasov wrote: > > Vegard Nossum is reporting for a crash in fib_dump_info (fib_nhs==1) > > when nh_dev = NULL. Problem happens when RTNH_F_LINKDOWN is > > provided from user space for

Re: [PATCH v6 04/12] net/mlx4_en: add support for fast rx drop bpf program

On Fri, Jul 8, 2016 at 5:15 AM, Brenden Blanco wrote: > Add support for the BPF_PROG_TYPE_XDP hook in mlx4 driver. > > In tc/socket bpf programs, helpers linearize skb fragments as needed > when the program touchs the packet data. However, in the pursuit of > speed, XDP

Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

Shmulik Ladkani wrote: > I'd appreciate any suggestion how to determine traffic is local OTHER > THAN testing IPSKB_FORWARDED; If we have such a way, there wouldn't be an > impact on local traffic. > > > What about setting IPCB FORWARD flag in iptunnel_xmit if

Re: [PATCH v6 01/12] bpf: add XDP prog type for early driver filter

On Sat, Jul 9, 2016 at 3:14 AM, Jesper Dangaard Brouer wrote: > On Thu, 7 Jul 2016 19:15:13 -0700 > Brenden Blanco wrote: > >> Add a new bpf prog type that is intended to run in early stages of the >> packet rx path. Only minimal packet metadata will be

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Fri, 8 Jul 2016 19:04:27 -0400 Hannes Frederic Sowa wrote: > >> I really do wonder if GRO on top of fragmentation does have any effect. > >> Would be great if someone has data for that already? > > > > I think that logic is kind of backwards. It is already

Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

On 09.07.2016 05:00, Florian Westphal wrote: > I am worried about this patch, skb_gso_validate_mtu is more costly than > the ->flags & FORWARD check; everyone pays this extra cost. > > What about setting IPCB FORWARD flag in iptunnel_xmit if > skb->skb_iif != 0... instead? That came to my mind

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On 09.07.2016 11:18, Shmulik Ladkani wrote: > On Fri, 8 Jul 2016 19:04:27 -0400 Hannes Frederic Sowa > wrote: I really do wonder if GRO on top of fragmentation does have any effect. Would be great if someone has data for that already? >>> >>> I think that

Re: [PATCH net] udp: prevent bugcheck if filter truncates packet too much

On Sat, Jul 9, 2016 at 6:43 AM, Michal Kubecek wrote: > On Sat, Jul 09, 2016 at 11:48:49AM +0200, Daniel Borkmann wrote: >> On 07/09/2016 02:20 AM, Alexei Starovoitov wrote: >> >On Sat, Jul 09, 2016 at 01:31:40AM +0200, Eric Dumazet wrote: >> >>On Fri, 2016-07-08 at 17:52 +0200,

Re: [PATCH v6 04/12] net/mlx4_en: add support for fast rx drop bpf program

On Fri, Jul 8, 2016 at 5:15 AM, Brenden Blanco wrote: > Add support for the BPF_PROG_TYPE_XDP hook in mlx4 driver. > > In tc/socket bpf programs, helpers linearize skb fragments as needed > when the program touchs the packet data. However, in the pursuit of nit, for the

Re: [PATCH net-next 0/4] net: cleanup for UDP tunnel's GRO

On Sat, 9 Jul 2016 11:35:03 -0400 Hannes Frederic Sowa wrote: > On 09.07.2016 11:18, Shmulik Ladkani wrote: > > On Fri, 8 Jul 2016 19:04:27 -0400 Hannes Frederic Sowa > > wrote: > I really do wonder if GRO on top of fragmentation

[PATCH net] ipv6: addrconf: fix Juniper SSL VPN client regression

The Juniper SSL VPN client use a "tun" interface and seems to be picky about visible changes.to it. Commit cc9da6cc4f56 ("ipv6: addrconf: use stable address generator for ARPHRD_NONE") made such interfaces get an auto-generated IPv6 link local address by default, similar to most other interface

Re: [PATCH net-next v2 0/4] net: support MPLS in IPv4 and UDP

From: Simon Horman Date: Thu, 7 Jul 2016 07:56:11 +0200 > This short series provides support for MPLS in IPv4 (RFC4023), and by > virtue of FOU, MPLS in UDP (RFC7510). Series applied, thanks Simon.

Re: [PATCH v2 0/6] net: ethernet: bgmac: Add platform device support

From: Jon Mason Date: Thu, 7 Jul 2016 19:08:52 -0400 > David Miller, Please consider including patches 1-5 in net-next Done.

Re: [PATCH net-next] ipv6: do not abuse GFP_ATOMIC in inet6_netconf_notify_devconf()

From: Eric Dumazet Date: Fri, 08 Jul 2016 05:46:04 +0200 > From: Eric Dumazet > > All inet6_netconf_notify_devconf() callers are in process context, > so we can use GFP_KERNEL allocations if we take care of not holding > a rwlock while not needed in

Re: [PATCH net] dccp: avoid deadlock in dccp_v4_ctl_send_reset

From: Eric Dumazet Date: Fri, 08 Jul 2016 11:03:57 +0200 > From: Eric Dumazet > > In the prep work I did before enabling BH while handling socket backlog, > I missed two points in DCCP : > > 1) dccp_v4_ctl_send_reset() uses bh_lock_sock(), assuming

[net-next:master 1099/1116] net/ipv4/tunnel4.c:226:1: warning: label 'err_ipv6' defined but not used

tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 927265bc6cd6374c9bafc43408ece4e92311b149 commit: 8afe97e5d4165c9d181d42504af3f96c8427659a [1099/1116] tunnels: support MPLS over IPv4 tunnels config: m32r-usrv_defconfig (attached as .config) compiler:

Re: [PATCH] tunnels: correct conditional build of MPLS

On Sun, Jul 10, 2016 at 09:20:54AM +0900, Simon Horman wrote: > * If MPLS is not enabled then err_mpls is not needed > * If IPV6 is not enabled then unregistering IPPROTO_IPV6 is not > needed in the error path and err_ipv6 is not needed > * When unregistering IPPROTO_IPV6 the tunnel64_protocol

Re: [PATCH] Need proper type casting before assignment, Remove compilation Warning.

From: Arvind Yadav Date: Fri, 8 Jul 2016 00:07:54 +0530 > -Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to > assigned in ucc_fast_tx_virtual_fifo_base_offset and > ucc_fast_rx_virtual_fifo_base_offset. These variable are 'unsigned int'. > So

Re: [PATCH net-next 0/3] r8152: remove the redundant code

From: Hayes Wang Date: Thu, 7 Jul 2016 15:09:17 +0800 > Remove the unnacessary code. Series applied.

Re: [PATCH net-next] ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf()

From: Eric Dumazet Date: Fri, 08 Jul 2016 05:18:24 +0200 > From: Eric Dumazet > > inet_forward_change() runs with RTNL held. > We are allowed to sleep if required. > > If we use __in_dev_get_rtnl() instead of __in_dev_get_rcu(), > we no longer have

Re: [PATCH net] ipv6: addrconf: fix Juniper SSL VPN client regression

Hi Bjorn, On Sat, Jul 9, 2016, at 23:13, Bjørn Mork wrote: > The Juniper SSL VPN client use a "tun" interface and seems to > be picky about visible changes.to it. Commit cc9da6cc4f56 > ("ipv6: addrconf: use stable address generator for ARPHRD_NONE") > made such interfaces get an auto-generated

[PATCH net-next v2] tunnels: correct conditional build of MPLS and IPv6

Using a combination if #if conditionals and goto labels to unwind tunnel4_init seems unwieldy. This patch takes a simpler approach of directly unregistering previously registered protocols when an error occurs. This fixes a number of problems with the current implementation including the

Re: [PATCH v6 04/12] net/mlx4_en: add support for fast rx drop bpf program

On Sat, Jul 9, 2016 at 10:58 PM, Saeed Mahameed wrote: > On Fri, Jul 8, 2016 at 5:15 AM, Brenden Blanco wrote: >> Add support for the BPF_PROG_TYPE_XDP hook in mlx4 driver. >> >> In tc/socket bpf programs, helpers linearize skb fragments as needed

Re: [PATCH net v2 0/4] ibmvnic driver bugfixes and improvements

From: Thomas Falcon Date: Fri, 8 Jul 2016 02:09:02 -0500 > Miscellaneous fixes and improvements on the ibmvnic driver. Series applied.

Re: [net-next PATCH V2] net: tracepoint napi:napi_poll add work and budget

From: Jesper Dangaard Brouer Date: Thu, 07 Jul 2016 18:01:32 +0200 > An important information for the napi_poll tracepoint is knowing > the work done (packets processed) by the napi_poll() call. Add > both the work done and budget, as they are related. > > Handle

[net-next:master 1099/1116] net/ipv4/tunnel4.c:223:1: warning: label 'err_mpls' defined but not used

tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 927265bc6cd6374c9bafc43408ece4e92311b149 commit: 8afe97e5d4165c9d181d42504af3f96c8427659a [1099/1116] tunnels: support MPLS over IPv4 tunnels config: arm-at91_dt_defconfig (attached as .config) compiler:

Re: [PATCH net] ipv6: addrconf: fix Juniper SSL VPN client regression

Hannes Frederic Sowa writes: > On Sat, Jul 9, 2016, at 23:13, Bjørn Mork wrote: >> The Juniper SSL VPN client use a "tun" interface and seems to >> be picky about visible changes.to it. Commit cc9da6cc4f56 >> ("ipv6: addrconf: use stable address generator for

Re: [PATCH net-next v2 0/4] net: support MPLS in IPv4 and UDP

On Sat, Jul 09, 2016 at 05:47:32PM -0400, David Miller wrote: > From: Simon Horman > Date: Thu, 7 Jul 2016 07:56:11 +0200 > > > This short series provides support for MPLS in IPv4 (RFC4023), and by > > virtue of FOU, MPLS in UDP (RFC7510). > > Series applied, thanks

[PATCH] tunnels: correct conditional build of MPLS

* If MPLS is not enabled then err_mpls is not needed * If IPV6 is not enabled then unregistering IPPROTO_IPV6 is not needed in the error path and err_ipv6 is not needed * When unregistering IPPROTO_IPV6 the tunnel64_protocol structure rather than the tunnel4_protocol structure should be used.

[net-next:master 1099/1116] net/ipv4/tunnel4.c:218:3: error: label 'err_mpls' used but not defined

tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 927265bc6cd6374c9bafc43408ece4e92311b149 commit: 8afe97e5d4165c9d181d42504af3f96c8427659a [1099/1116] tunnels: support MPLS over IPv4 tunnels config: x86_64-randconfig-s4-07101153 (attached as .config)