igh, const u8
> *lladdr, u8 new,
> goto out;
> } else {
> if (lladdr == neigh->ha && new == NUD_STALE &&
> - ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
> - (old & NUD_CONNECTED))
> - )
> - new = old;
> + !(flags & NEIGH_UPDATE_F_ADMIN))
> + goto out;
> }
> }
>
> Any thoughts?
This change makes perfectly sense to me.
Reviewed-by: Hannes Frederic Sowa
Thanks,
Hannes
an
> ingress interface that get udp-encaspulated as "allowed to be fragmented",
> causing their network_seglen to be validated by 'ip_finish_output_gso'
> (and fragment if needed).
>
> Note the TUNNEL_DONT_FRAGMENT tun_flag is still honoured (both in the
>
On 18.07.2016 13:49, Shmulik Ladkani wrote:
> This flag indicates whether fragmentation of segments is allowed.
>
> Formerly this policy was hardcoded according to IPSKB_FORWARDED (set by
> either ip_forward or ipmr_forward).
>
> Cc: Hannes Frederic Sowa
> Cc: Florian West
Hello,
On Mon, Jul 18, 2016, at 21:43, Andi Kleen wrote:
> > I wonder if this can be attacked from a different angle. What would be
> > missing to add support for this in user space? The first possibility
> > that came to my mind is to just multiplex those hints in the kernel.
>
> "just" is the h
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 applica
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
>>
>> I think this is reasonable, thanks!
>>
>> Acked-by: Hannes Frederic Sowa
>
> Thanks for the fe
EL_DONT_FRAGMENT tun_flag is still 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
> Cc: Florian Westphal
> Signed-off-by: Shmulik Ladkani
I think this is reasonable, thanks!
Acked-by: Hannes Frederic Sowa
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
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:
> > > >
> > > > > What about setting IPCB FORWARD flag in iptunnel_xmit
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: Valdis Kletnieks
>> Repo
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' which follows.
>
> I don't see a probl
On 09.07.2016 19:23, Bjørn Mork wrote:
> 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
>
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 IPv
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?
>>>
>
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 fi
On 08.07.2016 18:11, Alexander Duyck wrote:
> On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa
> wrote:
>> On 08.07.2016 17:27, Alexander Duyck wrote:
>>> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa
>>> wrote:
>>>> On 08.07.2016 16:17, Shmul
On 08.07.2016 17:19, Shmulik Ladkani wrote:
> On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa
> wrote:
>> On 08.07.2016 16:17, Shmulik Ladkani wrote:
>>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
>>> wrote:
>>>> I get that there is an
On 08.07.2016 17:27, Alexander Duyck wrote:
> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa
> wrote:
>> 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
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 the ingress device level. Currently both the gene
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 packets
>> are not admi
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 handled entirely
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 commodi
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
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 mai
ller
> ---
>
> I'll be pushing this to -stable branches as well.
Acked-by: Hannes Frederic Sowa
Actually a funny trick I learned from DragonflyBSD sources is to just
randomize the first two bytes of the rss key and replicate them to fill
up the the last 38 bytes (or more). Doing s
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.
> Opera
al underlying device.
>
> Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
> Signed-off-by: Daniel Borkmann
> Acked-by: Sabrina Dubroca
Acked-by: Hannes Frederic Sowa
Thanks!
ialized
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
Thanks!
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 before driver passes
>>>
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 specificati
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" requires
>>> access to
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 userl
On 17.06.2016 09:51, Tom Herbert wrote:
> On Thu, Jun 16, 2016 at 4:15 PM, Hannes Frederic Sowa
> wrote:
>> 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.
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 socket, a the full 4-tuple fo
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 udp_
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
>>
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 elimina
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
Also,
Acked-by: Hannes Frederic Sowa
, and if they don't support it then this will
> fix any issues where headers might be interpreted incorrectly.
>
> Signed-off-by: Alexander Duyck
Acked-by: Hannes Frederic Sowa
cked-by: Hannes Frederic Sowa
Also thanks for cleaning the Kconfig dust from all the drivers!
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
Acked-by: Hannes Frederic Sowa
;
> Signed-off-by: Alexander Duyck
Acked-by: Hannes Frederic Sowa
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 mechanism and things will
>>> see
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: dere
t;
> Cc: David S. Miller
> Cc: Alexey Kuznetsov
> Cc: James Morris
> Cc: Hideaki YOSHIFUJI
> Cc: Patrick McHardy
> Reviewed-by: Stefan Schmidt
> Acked-by: YOSHIFUJI Hideaki
> Signed-off-by: Alexander Aring
Acked-by: Hannes Frederic Sowa
Ah, I noticed I am too late
i YOSHIFUJI
> Cc: Patrick McHardy
> Acked-by: YOSHIFUJI Hideaki
> Reviewed-by: Stefan Schmidt
> Signed-off-by: Alexander Aring
Acked-by: Hannes Frederic Sowa
UJI
> Cc: Patrick McHardy
> Acked-by: YOSHIFUJI Hideaki
> Reviewed-by: Stefan Schmidt
> Signed-off-by: Alexander Aring
Acked-by: Hannes Frederic Sowa
UJI
> Cc: Patrick McHardy
> Acked-by: YOSHIFUJI Hideaki
> Reviewed-by: Stefan Schmidt
> Signed-off-by: Alexander Aring
Acked-by: Hannes Frederic Sowa
[note, patchworks picks up the acks automatically, you don't need to repost]
Thanks,
Hannes
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 interface MTU.
>>
>> This patc
er")
> Signed-off-by: Sabrina Dubroca
Acked-by: Hannes Frederic Sowa
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
Acked-by: Hannes Frederic Sowa
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
>> ---
>> diff
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);
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
On 13.06.2016 21:47, Alexander Duyck wrote:
> On Mon, Jun 13, 2016 at 10:57 AM, Hannes Frederic Sowa
> wrote:
>> Hi Alex,
>>
>> very cool series!
>>
>> On 13.06.2016 19:48, Alexander Duyck wrote:
>>> diff --git a/include/linux/netdevice.h b/inc
Unfortunately because of bisectability I cannot split this patch. :(
Signed-off-by: Hannes Frederic Sowa
---
drivers/net/bonding/bond_main.c | 3 +--
drivers/net/gtp.c | 3 ++-
drivers/net/ppp/pptp.c | 2 +-
drivers/net/vrf.c | 7 ---
include/net
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
Signed-off-by: Hannes Frederic Sowa
---
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 insertions(+), 23 deletions(-)
diff --git
No functional changes.
Signed-off-by: Hannes Frederic Sowa
---
include/net/flow.h | 21 -
include/net/route.h | 33 +++--
net/ipv4/inet_connection_sock.c | 41 +
net/ipv4/ip_output.c
unning NFS under UDP.
>
> Signed-off-by: Steven Caron
Awesome!
Acked-by: Hannes Frederic Sowa
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 port but provide a typ
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
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
Reported-by: Cong Wang
Cc: Cong Wang
Cc: Tom Herbert
Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6")
Signed-off-by: Hannes Frederic Sowa
---
net/ipv4/udp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/udp.c
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 accidentally break EC
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 sh
t was easier to explain in a pr_warn). Opinions?
Cc: Florian Westphal
Signed-off-by: Hannes Frederic Sowa
---
include/net/inet_ecn.h | 5 +
net/ipv4/fib_rules.c | 6 +-
net/ipv6/fib6_rules.c | 7 ++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/net/inet_ecn.
Cc: Tom Herbert
Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6")
Signed-off-by: Hannes Frederic Sowa
---
net/ipv6/ip6_checksum.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_checksum.c b/net/ipv6/ip6_checks
On Sat, Jun 11, 2016, at 20:56, Hannes Frederic Sowa wrote:
> Cc: Tom Herbert
> Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for
> UDP/IPv6")
> Signed-off-by: Hannes Frederic Sowa
Sorry for the noise, I will send a better patch in a minute.
Cc: Tom Herbert
Fixes: 4068579e1e098fa ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6")
Signed-off-by: Hannes Frederic Sowa
---
include/net/ip6_checksum.h | 2 +-
net/ipv6/ip6_checksum.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/ip6_
Cc: Florent Fourcot
Fixes: 1d13a96c74fc ("ipv6: tcp: fix flowlabel value in ACK messages send from
TIME_WAIT")
Signed-off-by: Hannes Frederic Sowa
---
net/ipv6/tcp_ipv6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ip
IPv6 ping socket error handler doesn't correctly convert the new 32 bit
mtu to host endianness before using.
Cc: Lorenzo Colitti
Fixes: 6d0bfe22611602f ("net: ipv6: Add IPv6 support to the ping socket.")
Signed-off-by: Hannes Frederic Sowa
---
net/ipv6/icmp.c | 2 +-
1
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:
Signed-off-by: Hannes Frederic Sowa
---
net/ipv6/icmp.c | 4 +++-
net/ipv6/ping.c | 4
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: d9be4f7a6f5a8da3133b832eca41c3591420b1ca
>>
>> Now we're f
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
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
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 corr
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
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 s
Hi,
On 27.05.2016 18:59, Tom Herbert wrote:
> On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan
> wrote:
>> On (05/27/16 11:53), Hannes Frederic Sowa wrote:
>>>> Thinking about this some more, the per option white list is a better
>>>> approach. If
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
>> which
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 mecha
w 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
>>>
>>> On (05/22/16 03:08), Hannes F
On 21.05.2016 22:02, Shmulik Ladkani wrote:
> On Sat, 21 May 2016 17:55:59 +0200 Hannes Frederic Sowa
> wrote:
>> On 21.05.2016 14:50, Shmulik Ladkani wrote:
>>> Hi,
>>>
>>> inet6_protocol's INET6_PROTO_FINAL flag denotes handler is expected not
&g
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
;>>>> 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-archi
t
> draft 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 Frederi
On 21.05.2016 18:00, Tom Herbert wrote:
> On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa
> wrote:
>> On 21.05.2016 17:19, Tom Herbert wrote:
>>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
>>> wrote:
>>>> On Sat, May 21, 2016, at 03:56,
On 21.05.2016 18:00, Tom Herbert wrote:
> On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa
> wrote:
>> On 21.05.2016 17:19, Tom Herbert wrote:
>>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
>>> wrote:
>>>> On Sat, May 21, 2016, at 03:56,
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:
>
>
On 21.05.2016 17:19, Tom Herbert wrote:
> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
> wrote:
>> 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
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
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 f
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 to
he 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
On Fri, May 20, 2016, at 03:56, Cong Wang wrote:
> On Thu, May 19, 2016 at 3:50 PM, Hannes Frederic Sowa
> wrote:
> > 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
> >> wrote
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
> wrote:
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index 2e3ebfe5549ef5..d56c0559b477cb 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv
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
---
drivers/net/geneve.c | 10 +++---
drivers/net/vxlan.c | 4 ++--
net/ipv4/udp.c | 2 +-
On 18.05.2016 22:43, Daniel Borkmann wrote:
> On 05/18/2016 04:56 PM, Eric W. Biederman wrote:
>> Hannes Frederic Sowa writes:
>>> On 18.05.2016 01:12, Eric W. Biederman wrote:
>>>>
>>>> While reviewing the filesystems that set FS_USERNS_MOUNT I spotte
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 facilit
301 - 400 of 908 matches
Mail list logo