Re: [RFC PATCH 00/30] Kernel NET policy

On 18.07.2016 17:45, Andi Kleen wrote: >> It seems strange to me to add such policies to the kernel. >> Addmittingly, documentation of some settings is non-existent and one needs >> various different tools to set this (sysctl, procfs, sysfs, ethtool, etc). > > The problem is that different

Re: [PATCH v2] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, allow segmentation for local udp tunneled skbs

On 18.07.2016 12:11, Shmulik Ladkani wrote: > On Mon, 18 Jul 2016 12:06:00 +0200, han...@stressinduktion.org wrote: >>> Signed-off-by: Shmulik Ladkani <shmulik.ladk...@gmail.com> >> >> I think this is reasonable, thanks! >> >> Acked-by: Hannes Frederic Sow

Re: [PATCH v2] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, allow segmentation for local udp tunneled skbs

till honoured (both in the > gso and non-gso cases), which serves users wishing to forbid > fragmentation at the udp tunnel endpoint. > > Cc: Hannes Frederic Sowa <han...@stressinduktion.org> > Cc: Florian Westphal <f...@strlen.de> > Signed-off-by: Shmulik Ladkani <shmulik.ladk...@gmail.com> I think this is reasonable, thanks! Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

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

Hello, On Thu, Jul 14, 2016, at 16:13, Shmulik Ladkani wrote: > Hi, > > On Thu, 14 Jul 2016 15:12:07 +0200, han...@stressinduktion.org wrote: > > I liked the fact that setting IPSKB_FORWARDED was only contained in > > vxlan and as such wouldn't have as much impact. It was more logically > > easy

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

Hello Shmulik, On Wed, Jul 13, 2016, at 16:00, Shmulik Ladkani wrote: > Hi Florian, Hannes, > > On Tue, 12 Jul 2016 08:56:56 +0300 Shmulik Ladkani > wrote: > > On Sat, 9 Jul 2016 15:22:30 +0200 Florian Westphal wrote: > > > > > > > > >

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

an choose to enable automatic LL generation by selecting a suitable >> addrgenmode. >> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=121131 >> Fixes: cc9da6cc4f56 ("ipv6: addrconf: use stable address generator for >> ARPHRD_NONE") >> Reported-by: Val

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

On 11.07.2016 04:15, Florian Westphal wrote: > Shmulik Ladkani wrote: >> OK with the general idea; However I don't want to abuse IPSKB_FORWARDED >> as the skb is not really "ip forwarded", and it might have undesirable >> affects, such as in 'ip_skb_dst_mtu'

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

On 09.07.2016 19:23, Bjørn Mork wrote: > Hannes Frederic Sowa <han...@stressinduktion.org> 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 ch

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

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 > <han...@stressinduktion.org> wrote: >>>> I really do wonder if GRO on top of fragmentation does have any effect. >>>> Would be great if someone has data

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 08.07.2016 18:11, Alexander Duyck wrote: > On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 08.07.2016 17:27, Alexander Duyck wrote: >>> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa >>>

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

On 08.07.2016 17:19, Shmulik Ladkani wrote: > On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 08.07.2016 16:17, Shmulik Ladkani wrote: >>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck >>> <alexand

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

On 08.07.2016 17:27, Alexander Duyck wrote: > On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 08.07.2016 16:17, Shmulik Ladkani wrote: >>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck >>> <alexander.du.

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

On 08.07.2016 16:17, Shmulik Ladkani wrote: > On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck > wrote: >> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: >>> With udp tunnel offload in place, the kernel can do GRO for some udp tunnels >>> at

Re: [PATCH net-next 2/4] udp offload: allow GRO on 0 checksum packets

On 08.07.2016 12:46, Alexander Duyck wrote: > On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote: >> currently, UDP packets with zero checksum are not allowed to >> use udp offload's GRO. This patch admits such packets to >> GRO, if the related socket settings allow it: ipv6

Re: [PATCH net-next 3/4] vxlan: remove gro_cell support

On 08.07.2016 11:33, Eric Dumazet wrote: > On Fri, 2016-07-08 at 11:12 -0400, Hannes Frederic Sowa wrote: >> Hi Eric, >> >> On 07.07.2016 12:13, Eric Dumazet wrote: >>> On Thu, 2016-07-07 at 17:58 +0200, Paolo Abeni wrote: >>>> GRO is now

Re: ipv6 issues after an DDoS for kernel 4.6.3

On 08.07.2016 11:38, Eric Dumazet wrote: > On Fri, 2016-07-08 at 11:28 -0400, Hannes Frederic Sowa wrote: >> On 08.07.2016 10:14, Eric Dumazet wrote: >>> On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote: >>>> I do run a 4.6.3 hardened Gentoo kernel at a co

Re: ipv6 issues after an DDoS for kernel 4.6.3

On 08.07.2016 10:14, Eric Dumazet wrote: > On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote: >> I do run a 4.6.3 hardened Gentoo kernel at a commodity i7 server. A >> DDoS with about 300 MBit/sec over 5 mins resulted an issue for ipv6 at >> that system. >> >> The IPv6 monitoring from my ISP

Re: [PATCH net-next 3/4] vxlan: remove gro_cell support

Hi Eric, On 07.07.2016 12:13, Eric Dumazet wrote: > On Thu, 2016-07-07 at 17:58 +0200, Paolo Abeni wrote: >> GRO is now handled entirely by the udp_offload layer and there is no need >> for trying it again at the device level. We can drop gro_cell usage, >> simplifying the driver a bit, while

Re: [PATCH] packet: Use symmetric hash for PACKET_FANOUT_HASH.

.@regit.org> > Signed-off-by: David S. Miller <da...@davemloft.net> > --- > > I'll be pushing this to -stable branches as well. Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Actually a funny trick I learned from DragonflyBSD sources is to just randomize th

Re: [PATCHv3 wl-drv-next 1/2] add basic register-field manipulation macros

On 01.07.2016 23:26, Jakub Kicinski wrote: > C bitfields are problematic and best avoided. Developers > interacting with hardware registers find themselves searching > for easy-to-use alternatives. Common approach is to define > structures or sets of macros containing mask and shift pair. >

Re: [PATCH net] macsec: set actual real device for xmit when !protect_frames

derlying device. > > Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") > Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> > Acked-by: Sabrina Dubroca <s...@queasysnail.net> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks!

Re: [PATCH] ipv4: Fix ip_skb_dst_mtu to use the sk passed by ip_finish_output

nitialized accordingly and I suspect people want to have vxlan to use the path mtu when transmitting packets, even during forwarding. Maybe this can be tweaked with an additional patch, if people want to change this behavior. But as your patch doesn't change any of this, Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks!

Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 22.06.2016 14:32, Alexander Duyck wrote: > On Wed, Jun 22, 2016 at 11:22 AM, Yuval Mintz wrote: >> This series adds driver support for the processing of tunnel >> [specifically vxlan/geneve/gre tunnels] packets which are >> aggregated [GROed] by the hardware

Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

On 21.06.2016 11:42, Tom Herbert wrote: >> > There is also some argument to be had for theory versus application. >> > Arguably it is the customers that are leading to some of the dirty >> > hacks as I think vendors are building NICs based on customer use cases >> > versus following any

Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

On 21.06.2016 10:27, Edward Cree wrote: > On 21/06/16 18:05, Alexander Duyck wrote: >> On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote: >>> But anyways, the vastness of the key is why we want to keep "sockets" >>> out of network cards, because proper support of "sockets"

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 17.06.2016 20:52, Tom Herbert wrote: > >> > Rather, I think people are going to start adding rules to block TOU >> > tunnels entirely because they cannot inspect nor conditionally >> > filter/rewrite the contents. This is even more likely if Joe Random >> > and so easily can do their own

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 17.06.2016 09:51, Tom Herbert wrote: > On Thu, Jun 16, 2016 at 4:15 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 16.06.2016 19:51, Tom Herbert wrote: >>> Transports over UDP is intended to encapsulate TCP and other transport >>> pr

Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

On 21.06.2016 01:22, David Miller wrote: > From: Tom Herbert > Date: Mon, 20 Jun 2016 10:05:01 -0700 > >> Generally, this means it needs to at least match by local addresses >> and port for an unconnected/unbound socket, the source address for >> an unconnected/bound

Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

On 20.06.2016 12:27, Tom Herbert wrote: >> Do we? >> >> We look up the socket in a proper way, inclusive the namespace belonging >> to the device we received the packet on. That said, I don't see a >> problem with that right now. But maybe I miss something? >> > When we so the socket lookup in

Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

Hello, On 20.06.2016 10:05, Tom Herbert wrote: >> And finally, he added a big comment explaining that new tunnel types >> should not be added to the tunnel type list, and those that exist >> should only be used for RX. >> >> Therefore, this isn't openning the door for new random offloads, quite

Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 16.06.2016 19:51, Tom Herbert wrote: > Transports over UDP is intended to encapsulate TCP and other transport > protocols directly and securely in UDP. > > The goal of this work is twofold: > > 1) Allow applications to run their own transport layer stack (i.e.from >userspace). This

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

to be a bit more protocol specific. > > I also went through and cleaned out a number of redundant includes that > where in the .h and .c files for these drivers. > > Signed-off-by: Alexander Duyck <adu...@mirantis.com> Also, Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

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

, and if they don't support it then this will > fix any issues where headers might be interpreted incorrectly. > > Signed-off-by: Alexander Duyck <adu...@mirantis.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

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

du...@mirantis.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Also thanks for cleaning the Kconfig dust from all the drivers!

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

th a naming scheme that consisted of using the > prefix udp_tunnel on function names. I applied this to the notifier and > ndo ops as well so that it hopefully points to the fact that these are > primarily used in the udp_tunnel functions. > > Signed-off-by: Alexander Duyck &

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

; > Signed-off-by: Alexander Duyck <adu...@mirantis.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

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

On 16.06.2016 23:18, David Miller wrote: > From: David Ahern > Date: Wed, 15 Jun 2016 14:29:28 -0600 > >> On 6/15/16 1:48 PM, David Miller wrote: >>> But if people don't use the helpers, and initialize flow structures >>> on their own, yeah that defeats the whole

Re: [Bug 120441] af_packet no longer uses symmetric hashing

On 16.06.2016 16:37, Daniel Borkmann wrote: > On 06/16/2016 03:57 PM, Derek Ditch wrote: > [...] >>> Begin forwarded message: >>> >>> From: bugzilla-dae...@bugzilla.kernel.org >>> Subject: [Bug 120441] af_packet no longer uses symmetric hashing >>> Date: June 16, 2016 at 07:35:54 -0500 >>> To:

Re: [PATCHv4 net-next 07/12] addrconf: put prefix address add in an own function

t <ste...@osg.samsung.com> > Acked-by: YOSHIFUJI Hideaki <yoshf...@linux-ipv6.org> > Signed-off-by: Alexander Aring <a...@pengutronix.de> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Ah, I noticed I am too late for the Acks but go through the rest of the series anyway. :)

Re: [PATCHv4 net-next 06/12] ndisc: add __ndisc_fill_addr_option function

c.ru> > Cc: James Morris <jmor...@namei.org> > Cc: Hideaki YOSHIFUJI <yoshf...@linux-ipv6.org> > Cc: Patrick McHardy <ka...@trash.net> > Acked-by: YOSHIFUJI Hideaki <yoshf...@linux-ipv6.org> > Reviewed-by: Stefan Schmidt <ste...@osg.samsung.com> > Sign

Re: [PATCHv4 net-next 05/12] ndisc: add __ndisc_opt_addr_data function

t; > Cc: James Morris <jmor...@namei.org> > Cc: Hideaki YOSHIFUJI <yoshf...@linux-ipv6.org> > Cc: Patrick McHardy <ka...@trash.net> > Acked-by: YOSHIFUJI Hideaki <yoshf...@linux-ipv6.org> > Reviewed-by: Stefan Schmidt <ste...@osg.samsung.com> > Signed-of

Re: [PATCHv4 net-next 04/12] ndisc: add __ndisc_opt_addr_space function

t; > Cc: James Morris <jmor...@namei.org> > Cc: Hideaki YOSHIFUJI <yoshf...@linux-ipv6.org> > Cc: Patrick McHardy <ka...@trash.net> > Acked-by: YOSHIFUJI Hideaki <yoshf...@linux-ipv6.org> > Reviewed-by: Stefan Schmidt <ste...@osg.samsung.com> > Sign

Re: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is set.

On 31.05.2016 20:39, David Miller wrote: > From: Alan Davey > Date: Mon, 23 May 2016 15:23:45 +0100 > >> One of the bugs documented in the raw(7) man page is as follows: When the >> IP_HDRINCL option is set, datagrams will not be fragmented and are limited to >> the

Re: [PATCH net 2/3] macsec: allocate sg and iv on the heap

river") > Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net 1/3] macsec: add rcu_barrier() on module exit

On 14.06.2016 15:25, Sabrina Dubroca wrote: > Without this, the various uses of call_rcu could cause a kernel panic. > > Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") > Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> Acked-b

Re: [PATCH RFC 3/3] ipv4: kill RTO_ONLINK, RT_CONN_FLAGS and RT_CONN_FLAGS_TOS

On 14.06.2016 08:29, Julian Anastasov wrote: > > Hello, > > On Mon, 13 Jun 2016, Hannes Frederic Sowa wrote: > >> Unfortunately because of bisectability I cannot split this patch. :( >> >> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org

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

On 14.06.2016 08:02, Julian Anastasov wrote: > > Hello, > > On Mon, 13 Jun 2016, Hannes Frederic Sowa wrote: > >> -flowi4_init_output(fl4, oif, sk->sk_mark, tos, RT_SCOPE_UNIVERSE, >> - protocol, flow_flags, dst, src, dport, sport);

Re: [PATCH net] fib_rules: don't break ECN with TOS rules

On Mon, Jun 13, 2016, at 00:18, David Ahern wrote: > On 6/11/16 3:10 PM, Hannes Frederic Sowa wrote: > > @@ -215,6 +216,9 @@ static int fib4_rule_configure(struct fib_rule *rule, > > struct sk_buff *skb, > > rule4->dst_len = frh->dst_len; > > rule4->dst

Re: [net-next PATCH 02/15] net: Merge VXLAN and GENEVE push notifiers into a single notifier

On 13.06.2016 21:47, Alexander Duyck wrote: > On Mon, Jun 13, 2016 at 10:57 AM, Hannes Frederic Sowa > <han...@redhat.com> wrote: >> Hi Alex, >> >> very cool series! >> >> On 13.06.2016 19:48, Alexander Duyck wrote: >>> diff --git a/include/linu

[PATCH RFC 3/3] ipv4: kill RTO_ONLINK, RT_CONN_FLAGS and RT_CONN_FLAGS_TOS

Unfortunately because of bisectability I cannot split this patch. :( Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/bonding/bond_main.c | 3 +-- drivers/net/gtp.c | 3 ++- drivers/net/ppp/pptp.c | 2 +- drivers/net

[PATCH RFC 0/3] ipv4: preparation work for making ipv4 routing ecn robust

question is, if this is acceptable. Especially because it removes the flowi4_init_output and flowi4_update_output functions and expands them inline. I did so to easy code review with grepping and finally not being forced to count the arguments. Opinions before I go on? Thanks! Hannes Frederic Sowa (3

[PATCH RFC 2/3] ipv4: make flow functions more grepable by removing flowi4_update_output

Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/flow.h | 11 --- include/net/route.h | 8 net/netfilter/ipvs/ip_vs_xmit.c | 9 +++-- net/sctp/protocol.c | 10 -- 4 files changed, 15 inse

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

No functional changes. Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/flow.h | 21 - include/net/route.h | 33 +++-- net/ipv4/inet_connection_sock.

Re: [PATCH v1 1/1] ipv4: Prevent malformed UFO fragments in ip_append_page

g NFS under UDP. > > Signed-off-by: Steven Caron <steven.ca...@genband.com> Awesome! Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [net-next PATCH 04/15] bnxt: Replace ndo_add/del_vxlan_port with ndo_add/del_udp_enc_port

On 13.06.2016 20:41, Jesse Gross wrote: > On Mon, Jun 13, 2016 at 10:48 AM, Alexander Duyck wrote: >> This change replaces the network device operations for adding or removing a >> VXLAN port with operations that are more generically defined to be used for >> any UDP offload

Re: [net-next PATCH 02/15] net: Merge VXLAN and GENEVE push notifiers into a single notifier

Hi Alex, very cool series! On 13.06.2016 19:48, Alexander Duyck wrote: > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index d101e4d904ba..e959b6348f91 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -1269,6 +1269,14 @@ struct net_device_ops

Re: [PATCH net] fib_rules: don't break ECN with TOS rules

On Sun, Jun 12, 2016, at 11:28, Julian Anastasov wrote: > > Hello, > > On Sun, 12 Jun 2016, Hannes Frederic Sowa wrote: > > > On Sun, Jun 12, 2016, at 02:09, Julian Anastasov wrote: > > > > > > Well, may be the confusion comes from commit 89aef892

[PATCH net] ipv4: fix checksum annotation in udp4_csum_init

Reported-by: Cong Wang <xiyou.wangc...@gmail.com> Cc: Cong Wang <xiyou.wangc...@gmail.com> Cc: Tom Herbert <t...@herbertland.com> Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6") Signed-off-by: Hannes Frederic Sowa <han...@stressindukti

Re: [PATCH net] fib_rules: don't break ECN with TOS rules

On Sun, Jun 12, 2016, at 02:36, Hannes Frederic Sowa wrote: > On Sun, Jun 12, 2016, at 02:09, Julian Anastasov wrote: > > > > Hello, > > > > On Sat, 11 Jun 2016, Hannes Frederic Sowa wrote: > > > > > Users of ToS rules could accidentall

Re: [PATCH net] fib_rules: don't break ECN with TOS rules

Hi Julian, On Sun, Jun 12, 2016, at 02:09, Julian Anastasov wrote: > > Hello, > > On Sat, 11 Jun 2016, Hannes Frederic Sowa wrote: > > > Users of ToS rules could accidentally break ECN, this patch tries to > > fix this in a way so we don't break shell s

[PATCH net] fib_rules: don't break ECN with TOS rules

to explain in a pr_warn). Opinions? Cc: Florian Westphal <f...@strlen.de> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/inet_ecn.h | 5 + net/ipv4/fib_rules.c | 6 +- net/ipv6/fib6_rules.c | 7 ++- 3 files changed, 16 insertions(+), 2 deleti

[PATCH net v2] ipv6: fix checksum annotation in udp6_csum_init

Cc: Tom Herbert <t...@herbertland.com> Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6") Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/ipv6/ip6_checksum.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)

Re: [PATCH net] ipv6: fix checksum annotation in udp6_csum_init

On Sat, Jun 11, 2016, at 20:56, Hannes Frederic Sowa wrote: > Cc: Tom Herbert <t...@herbertland.com> > Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for > UDP/IPv6") > Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> Sorry f

[PATCH net] ipv6: fix checksum annotation in udp6_csum_init

Cc: Tom Herbert <t...@herbertland.com> Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6") Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/ip6_checksum.h | 2 +- net/ipv6/ip6_checksum.c| 2 +- 2 files chang

[PATCH net] ipv6: tcp: fix endianness annotation in tcp_v6_send_response

Cc: Florent Fourcot <florent.four...@enst-bretagne.fr> Fixes: 1d13a96c74fc ("ipv6: tcp: fix flowlabel value in ACK messages send from TIME_WAIT") Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/ipv6/tcp_ipv6.c | 4 ++-- 1 file changed, 2 inse

[PATCH net] ipv6: fix endianness error in icmpv6_err

IPv6 ping socket error handler doesn't correctly convert the new 32 bit mtu to host endianness before using. Cc: Lorenzo Colitti <lore...@google.com> Fixes: 6d0bfe22611602f ("net: ipv6: Add IPv6 support to the ping socket.") Signed-off-by: Hannes Frederic Sowa <han...@

[PATCH net-next] ipv6: use TOS marks from sockets for routing decision

In IPv6 the ToS values are part of the flowlabel in flowi6 and get extracted during fib rule lookup, but we forgot to correctly initialize the flowlabel before the routing lookup. Reported-by: <liam.mcbir...@boeing.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org&

Re: ipv4: Constrain UFO fragment sizes to multiples of 8 bytes

On 09.06.2016 06:59, Cong Wang wrote: > (Cc'ing netdev...) > > On Mon, Jun 6, 2016 at 1:24 PM, Steven Caron wrote: >> Back in 2011, Bill Sommerfeld submitted an update to prevent ip_append_data >> to create malformed packets: >> Commit:

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

On 07.06.2016 22:42, Philip Prindeville wrote: > On 06/07/2016 02:23 PM, Hannes Frederic Sowa wrote: >> >> On Tue, Jun 7, 2016, at 21:48, Philip Prindeville wrote: >>> static struct rtnl_link_ops ipgre_link_ops __read_mostly = { >>> diff --git a/net/ipv4/i

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

On Tue, Jun 7, 2016, at 21:48, Philip Prindeville wrote: > static struct rtnl_link_ops ipgre_link_ops __read_mostly = { > diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c > index d8f5e0a..95649eb 100644 > --- a/net/ipv4/ip_tunnel.c > +++ b/net/ipv4/ip_tunnel.c > @@ -682,7 +682,7 @@ void

Re: Fwd: Loopback properties in routing on linux kernel

On 07.06.2016 12:46, Krishna Mohan wrote: > HI All, > I have a question to determine the uses of multiple loopbacks > interfaces(int loopback) in routing(quagga) on linux kernel. Please > apologise if it is a dumb question. This is what I understand, please > clarify if my understanding is

Re: [RFC 01/12] add basic register-field manipulation macros

On 02.06.2016 01:08, Jakub Kicinski wrote: > On Wed, 01 Jun 2016 22:15:36 +0200, Hannes Frederic Sowa wrote: >> Hello, >> >> On Wed, Jun 1, 2016, at 18:50, Jakub Kicinski wrote: >>> C bitfields are problematic and best avoided. Developers >>> interacting

Re: [RFC 01/12] add basic register-field manipulation macros

Hello, On Wed, Jun 1, 2016, at 18:50, Jakub Kicinski wrote: > C bitfields are problematic and best avoided. Developers > interacting with hardware registers find themselves searching > for easy-to-use alternatives. Common approach is to define > structures or sets of macros containing mask and

Re: IPv6 extension header privileges

Hi, On 27.05.2016 18:59, Tom Herbert wrote: > On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan > <sowmini.varad...@oracle.com> wrote: >> On (05/27/16 11:53), Hannes Frederic Sowa wrote: >>>> Thinking about this some more, the per option white list is a better >

Re: [RFC 04/12] ndisc: get rid off dev parameter in ndisc_opt_addr_space

On 25.05.2016 07:15, YOSHIFUJI Hideaki wrote: > > > Alexander Aring wrote: >> This patch removes the net_device parameter from ndisc_opt_addr_space >> function. This can be useful for calling such functionality which >> doesn't depends on dev parameter. For current existing functionality >>

Re: IPv6 extension header privileges

On Thu, May 26, 2016, at 20:42, Tom Herbert wrote: > Thinking about this some more, the per option white list is a better > approach. If we allow an open ended mechanism for applications to > signal the network with arbitrary data (like user specified hbp > options would be), then use of that

Re: IPv6 extension header privileges

don't >>>>>>>>> allow setting EH. I would like to avoid that :-) >>> >>>> On 21.05.2016 19:46, Sowmini Varadhan wrote: >>>>> Do you mean this >>>>> http://www.ietf.org/mail-archive/web/spud/current/msg00365.html

Re: Missing INET6_PROTO_FINAL in l2tp_ip6_protocol?

On 21.05.2016 22:02, Shmulik Ladkani wrote: > On Sat, 21 May 2016 17:55:59 +0200 Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 21.05.2016 14:50, Shmulik Ladkani wrote: >>> Hi, >>> >>> inet6_protocol's INET6_PROTO_FINAL flag d

Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for unsupported GSO

On 22.05.2016 09:44, Michael S. Tsirkin wrote: > On Sat, May 21, 2016 at 03:02:30AM +0200, Hannes Frederic Sowa wrote: >> Hello, >> >> On 18.05.2016 18:06, Tom Herbert wrote: >>> In several gso_segment functions there are checks of gso_type against >>> a seem

Re: IPv6 extension header privileges

gt;> reinventing IP extensibility within UDP since the kernel APIs don't >>>>>>> allow setting EH. I would like to avoid that :-) > >> On 21.05.2016 19:46, Sowmini Varadhan wrote: >>> Do you mean this >>> http://www.ietf.org/mail-archive/web/spud/cur

Re: IPv6 extension header privileges

seems to be arguing for reinventing tcp congavoid and windowing > on top of udp to bypass kernel? ;-) Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw extension headers mentioned but haven't grasped why they deem necessary. > Hannes Frederic Sowa wrote: >>>>

Re: IPv6 extension header privileges

On 21.05.2016 18:00, Tom Herbert wrote: > On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 21.05.2016 17:19, Tom Herbert wrote: >>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa >>> <han...@stressin

Re: IPv6 extension header privileges

On 21.05.2016 18:00, Tom Herbert wrote: > On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 21.05.2016 17:19, Tom Herbert wrote: >>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa >>> <han...@stressin

Re: Missing INET6_PROTO_FINAL in l2tp_ip6_protocol?

On 21.05.2016 14:50, Shmulik Ladkani wrote: > Hi, > > inet6_protocol's INET6_PROTO_FINAL flag denotes handler is expected not > to request resubmission for local delivery. > > For an INET6_PROTO_FINAL handler, the following actions gets executed > prior delivery, in ip6_input_finish: > >

Re: IPv6 extension header privileges

On 21.05.2016 17:19, Tom Herbert wrote: > On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote: >>> On (05/21/16 02:20), Hannes Frederic Sowa wrote: >>>> >>

Re: IPv6 extension header privileges

On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote: > On (05/21/16 02:20), Hannes Frederic Sowa wrote: > > > > There are some options inherently protocol depending like the jumbo > > payload option, which should be under control of the kernel, or the > > router a

Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for unsupported GSO

Hello, On 18.05.2016 18:06, Tom Herbert wrote: > In several gso_segment functions there are checks of gso_type against > a seemingly arbitrary list of SKB_GSO_* flags. This seems like an > attempt to identify unsupported GSO types, but since the stack is > the one that set these GSO types in the

Re: IPv6 extension header privileges

On 21.05.2016 00:37, Tom Herbert wrote: > Hi, > > In ipv6_sockglue.c I noticed: > > /* hop-by-hop / destination options are privileged option */ > retv = -EPERM; > if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW)) >break; > > Can anyone provide that rationale as

Re: [PATCH net] bpf: Use mount_nodev not mount_ns to mount the bpf filesystem

o the mount namespace it can not possibly be correct to > store the mount namespace on the superblock as it does. > > Replace mount_ns with mount_nodev so that each mount of the bpf > filesystem returns a distinct instance, and the code is not buggy. > > In discussion with Hannes Fre

Re: [PATCH net] udp: prevent skbs lingering in tunnel socket queues

On Fri, May 20, 2016, at 03:56, Cong Wang wrote: > On Thu, May 19, 2016 at 3:50 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > Hi Cong, > > > > On Fri, May 20, 2016, at 00:33, Cong Wang wrote: > >> On Thu, May 19, 2016 at

Re: [PATCH net] udp: prevent skbs lingering in tunnel socket queues

Hi Cong, On Fri, May 20, 2016, at 00:33, Cong Wang wrote: > On Thu, May 19, 2016 at 6:58 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c > > index 2e3ebfe5549ef5..d56c0559b477cb 100644 > > --- a/net

[PATCH net] udp: prevent skbs lingering in tunnel socket queues

shouldn't put the skb back into the socket queue, no one will pick them up there. Instead we can simply discard them in the respective encap_recv functions. Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/geneve.c | 10 +++--- drivers/net/vxlan.c | 4 ++-

Re: [RFC][PATCH net] bpf: Use mount_nodev not mount_ns to mount the bpf filesystem

On 18.05.2016 22:43, Daniel Borkmann wrote: > On 05/18/2016 04:56 PM, Eric W. Biederman wrote: >> Hannes Frederic Sowa <han...@stressinduktion.org> writes: >>> On 18.05.2016 01:12, Eric W. Biederman wrote: >>>> >>>> While reviewing the filesystems

Re: [PATCH net] bpf: rather use get_random_int for randomizations

On 18.05.2016 15:20, Eric Dumazet wrote: > On Wed, 2016-05-18 at 14:14 +0200, Daniel Borkmann wrote: >> Start address randomization and blinding in BPF currently use >> prandom_u32(). prandom_u32() values are not exposed to unpriviledged >> user space to my knowledge, but given other kernel

Re: [RFC][PATCH net] bpf: Use mount_nodev not mount_ns to mount the bpf filesystem

On 18.05.2016 01:12, Eric W. Biederman wrote: > > While reviewing the filesystems that set FS_USERNS_MOUNT I spotted the > bpf filesystem. Looking at the code I saw a broken usage of mount_ns > with current->nsproxy->mnt_ns. As the code does not acquire a reference > to the mount namespace it

Re: [PATCH] net: af_unix: protect ->sk_shutdown change with lock_sock()

On 18.05.2016 12:14, Andrey Ryabinin wrote: > ->sk_shutdown bits share one bitfield with some other bits in sock struct, > such as ->sk_no_check_[r,t]x, ->sk_userlocks ... > sock_setsockopt() may write to these bits, while holding the socket lock. > In case of AF_UNIX sockets, we change

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 11.05.2016 16:45, Eric Dumazet wrote: > On Wed, May 11, 2016 at 7:38 AM, Paolo Abeni wrote: > >> Uh, we have likely the same issue in the net_rx_action() function, which >> also execute with bh disabled and check for jiffies changes even on >> single core hosts ?!? > >

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 11.05.2016 15:39, Hannes Frederic Sowa wrote: > I am fine with that. It is us to show clear benefits or use cases for > that. If we fail with that, no problem at all that the patches get > rejected, we don't want to add bloat to the kernel, for sure! At this > point I still think a

<    1   2   3   4   5   6   7   8   9   >