Re: [patch net-next v2 09/11] ipv4: fib: Add an API to request a FIB dump

On 23.11.2016 20:53, Ido Schimmel wrote: > On Wed, Nov 23, 2016 at 06:47:03PM +0100, Hannes Frederic Sowa wrote: >> Hmm, I think you need to read the sequence counter under rtnl_lock to >> have an ordering with the rest of the updates to the RCU trie. Otherwise >> you don't

Re: [patch net-next v2 09/11] ipv4: fib: Add an API to request a FIB dump

On 23.11.2016 15:34, Jiri Pirko wrote: > From: Ido Schimmel > > Commit b90eb7549499 ("fib: introduce FIB notification infrastructure") > introduced a new notification chain to notify listeners (f.e., switchdev > drivers) about addition and deletion of routes. > > However,

Re: [patch net-next v2 10/11] mlxsw: spectrum_router: Request a dump of FIB tables during init

On Wed, Nov 23, 2016, at 18:04, Jiri Pirko wrote: > >Sure, but an abort function can be provided to the kernel anyway and the > >driver can care about that. > > Ok, how? I think just a sysctl ontop of this series is enough plus a pr_warn. Rocker and mlxsw are responsible to loop for a maximum

Re: [patch net-next v2 10/11] mlxsw: spectrum_router: Request a dump of FIB tables during init

On Wed, Nov 23, 2016, at 17:04, Jiri Pirko wrote: > Wed, Nov 23, 2016 at 05:00:00PM CET, han...@stressinduktion.org wrote: > >On Wed, Nov 23, 2016, at 15:48, Jiri Pirko wrote: > >> From: Ido Schimmel > >> > >> Make sure the device has a complete view of the FIB tables by

Re: [patch net-next v2 10/11] mlxsw: spectrum_router: Request a dump of FIB tables during init

On Wed, Nov 23, 2016, at 15:48, Jiri Pirko wrote: > From: Ido Schimmel > > Make sure the device has a complete view of the FIB tables by invoking > their dump during module init. > > Signed-off-by: Ido Schimmel > Signed-off-by: Jiri Pirko

Re: net/arp: ARP cache aging failed.

On 23.11.2016 13:05, Eric Dumazet wrote: > On Wed, 2016-11-23 at 10:33 +0200, Julian Anastasov wrote: >> Hello, >> >> On Wed, 23 Nov 2016, yuehaibing wrote: >> >>> As to my topo,HOST1 and HOST3 share one route on HOST2, tcp connection >>> between HOST2 and HOST3 may call tcp_ack to set

Re: [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check

On 23.11.2016 05:45, Rohit Thapliyal wrote: > |>On 22.11.2016 07:27, Manjeet Pawar wrote: > >> From: Rohit Thapliyal > > >> > >> np checked for NULL and then dereferenced. It should be modified > >> for NULL case. > >> > >>

Re: [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check

On 22.11.2016 07:27, Manjeet Pawar wrote: > From: Rohit Thapliyal > > np checked for NULL and then dereferenced. It should be modified > for NULL case. > > Signed-off-by: Rohit Thapliyal > Signed-off-by: Manjeet Pawar >

Re: [PATCH] net: ipv6: avoid errors due to per-cpu atomic alloc

On 22.11.2016 11:34, Mike Manning wrote: > Bursts of failures may occur when adding IPv6 routes via Netlink to the > kernel when testing under scale (e.g. 500 routes lost out of 1M). The > reason is that percpu.c:pcpu_balance_workfn() is not guaranteed to have > extended the area map in time for

Re: [PATCH net] ipv6 addrconf: Implemented enhanced DAD (RFC7527)

Hi, On 21.11.2016 18:10, Erik Nordmark wrote: > On 11/16/16 10:49 PM, Hannes Frederic Sowa wrote: >> I thought about even removing the sysctl altogether and enable enhanced >> DAD by default. ;) >> >> I am in favor of enabling it by default. >> >&g

Re: net: BUG still has locks held in unix_stream_splice_read

On 17.11.2016 22:44, Cong Wang wrote: > On Sun, Oct 9, 2016 at 8:14 PM, Al Viro wrote: >> E.g what will happen if some code does a read on AF_UNIX socket with >> some local mutex held? AFAICS, there are exactly two callers of >> freezable_schedule_timeout() - this one

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

On 17.11.2016 19:32, Ido Schimmel wrote: > On Thu, Nov 17, 2016 at 06:20:39PM +0100, Hannes Frederic Sowa wrote: >> On 17.11.2016 17:45, David Miller wrote: >>> From: Hannes Frederic Sowa <han...@stressinduktion.org> >>> Date: Thu, 17 Nov 2016 15:36:48 +0100 >

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

On 17.11.2016 19:16, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Thu, 17 Nov 2016 18:20:39 +0100 > >> Hi, >> >> On 17.11.2016 17:45, David Miller wrote: >>> From: Hannes Frederic Sowa <han...@stressinduktion.o

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

Hi, On 17.11.2016 17:45, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Thu, 17 Nov 2016 15:36:48 +0100 > >> The other way is the journal idea I had, which uses an rb-tree with >> timestamps as keys (can be lamport timestamps

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

On 17.11.2016 14:10, Ido Schimmel wrote: > Hi Hannes, > > On Wed, Nov 16, 2016 at 08:43:25PM +0100, Hannes Frederic Sowa wrote: >> On 16.11.2016 19:51, Ido Schimmel wrote: >>> On Wed, Nov 16, 2016 at 06:35:45PM +0100, Hannes Frederic Sowa wrote: >>>> On

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

On 16.11.2016 19:51, Ido Schimmel wrote: > Hi, > > On Wed, Nov 16, 2016 at 06:35:45PM +0100, Hannes Frederic Sowa wrote: >> On 16.11.2016 16:18, Ido Schimmel wrote: >>> On Wed, Nov 16, 2016 at 03:51:01PM +0100, Hannes Frederic Sowa wrote: >>>> On 16.11.2016

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

On 16.11.2016 16:18, Ido Schimmel wrote: > Hi Hannes, > > On Wed, Nov 16, 2016 at 03:51:01PM +0100, Hannes Frederic Sowa wrote: >> On 16.11.2016 15:09, Jiri Pirko wrote: >>> From: Ido Schimmel <ido...@mellanox.com> >>> >>> Commit b90eb7549499

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

On 16.11.2016 17:27, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Wed, 16 Nov 2016 15:51:01 +0100 > >> I don't see a way around doing a journal like in filesystems somehow, > > We really just need a sequence counter increme

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

On 16.11.2016 15:09, Jiri Pirko wrote: > From: Ido Schimmel > > Commit b90eb7549499 ("fib: introduce FIB notification infrastructure") > introduced a new notification chain to notify listeners (f.e., switchdev > drivers) about addition and deletion of routes. > > However,

Re: [PATCH net] ipv6 addrconf: Implemented enhanced DAD (RFC7527)

Hello, On 16.11.2016 01:44, Erik Nordmark wrote: > On 11/16/16 1:00 AM, Hannes Frederic Sowa wrote: >> On 15.11.2016 08:57, Erik Nordmark wrote: >>> Implemented RFC7527 Enhanced DAD. >>> IPv6 duplicate address detection can fail if there is some temporary >>>

Re: [PATCH net] ipv6 addrconf: Implemented enhanced DAD (RFC7527)

On 15.11.2016 08:57, Erik Nordmark wrote: > Implemented RFC7527 Enhanced DAD. > IPv6 duplicate address detection can fail if there is some temporary > loopback of Ethernet frames. RFC7527 solves this by including a random > nonce in the NS messages used for DAD, and if an NS is received with the >

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

Hey Jason, On 15.11.2016 01:45, Jason A. Donenfeld wrote: > I'll have a better look at this. Perhaps this should be modeled on > what we currently do for userspace, which might amount to something > more or less like: Cool, thanks! > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c >

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On Mon, Nov 14, 2016, at 18:48, David Ahern wrote: > On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote: > >>>>> I just also quickly read up on the history (sorry was travelling last > >>>>> week) and wonder if you ever saw a user space facing bug or if this i

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On 14.11.2016 18:17, David Ahern wrote: > On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote: >> On 14.11.2016 17:55, David Ahern wrote: >>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: >>>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: >>>

Re: Long delays creating a netns after deleting one (possibly RCU related)

Hi Cong, On Sat, Nov 12, 2016, at 01:55, Cong Wang wrote: > On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney > wrote: > > > > Ah! This net_mutex is different than RTNL. Should synchronize_net() be > > modified to check for net_mutex being held in addition to the

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On 14.11.2016 17:55, David Ahern wrote: > On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: >> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: >>> This puts the IPv6 routing functions in parity with the IPv4 routing >>> functions. Namely, we now check in v

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: > This puts the IPv6 routing functions in parity with the IPv4 routing > functions. Namely, we now check in v6 that if a flowi6 requests an > saddr, the returned dst actually corresponds to a net device that has > that saddr. This mirrors

Re: Source address fib invalidation on IPv6

On Sun, Nov 13, 2016, at 01:43, Jason A. Donenfeld wrote: > On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld > wrote: > >> Gotcha. I don't see any checks that the saddr is valid similar to what > >> IPv4 does. > >> > >> I think the right place to add a check is in

Re: Why are IPv6 host and anycast routes referencing lo device?

On 08.11.2016 02:08, David Ahern wrote: > > Can anyone explain why host routes and anycast routes for IPv6 are added with > the device set to loopback versus the device with the address: > > local ::1 dev lo proto none metric 0 pref medium > local 2000:1:: dev lo proto none metric 0 pref

Re: [PATCH] net-ipv6: on device mtu change do not add mtu to mtu-less routes

hange_route(struct rt6_info *rt, > void *p_arg) > PMTU discouvery. >*/ > if (rt->dst.dev == arg->dev && > + dst_metric_raw(>dst, RTAX_MTU) && > !dst_metric_locked(>dst, RTAX_MTU)) { > if (rt->rt6i_flags & RTF_CACHE) { > /* For RTF_CACHE with rt6i_pmtu == 0 > Yep, that makes sense. Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net-next] sock: do not set sk_err in sock_dequeue_err_skb

eduma...@google.com> > Signed-off-by: Willem de Bruijn <will...@google.com> > Signed-off-by: Neal Cardwell <ncardw...@google.com> I think it makes sense to remove this given your argumentation. Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()

On 03.11.2016 22:05, Lance Richardson wrote: >> From: "Shmulik Ladkani" >> To: "Lance Richardson" , f...@strlen.de, >> han...@stressinduktion.org >> Cc: netdev@vger.kernel.org, jtl...@redhat.com >> Sent: Thursday, November 3, 2016 4:27:51 PM >>

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 02.11.2016 23:54, Thomas Graf wrote: > On 1 November 2016 at 16:12, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 01.11.2016 21:59, Thomas Graf wrote: >>>> Dumping and verifying which routes get used might actually already be >>>&

Re: [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()

On 03.11.2016 08:42, Shmulik Ladkani wrote: > On Wed, 2 Nov 2016 16:36:17 -0400 > Lance Richardson wrote: > >> -/* common case: fragmentation of segments is not allowed, >> - * or seglen is <= mtu >> +/* common case: seglen is <= mtu >> */ >> -if

Re: [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()

iperf (observing CPU usage and bandwidth) > have shown no measurable performance impact for traffic not > requiring fragmentation. > > Fixes: c7ba65d7b649 ("net: ip: push gso skb forwarding handling down the > stack") > Reported-by: Jan Tluka <jtl...@redhat.com> > Sig

Re: [PATCH net] ipv4: allow local fragmentation in ip_finish_output_gso()

> Signed-off-by: Lance Richardson <lrich...@redhat.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

Hi Tom, On Wed, Nov 2, 2016, at 00:07, Tom Herbert wrote: > On Tue, Nov 1, 2016 at 3:12 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > On 01.11.2016 21:59, Thomas Graf wrote: > >> On 1 November 2016 at 13:08, Hannes Frederic Sowa > >>

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 01.11.2016 21:59, Thomas Graf wrote: > On 1 November 2016 at 13:08, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote: >>> If I understand you correctly then a single BPF program would be >>&

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote: > On 1 November 2016 at 03:54, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > I do fear the complexity and debugability introduced by this patch set > > quite a bit. > > What is the complexity co

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On 01.11.2016 17:39, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Tue, 1 Nov 2016 17:27:56 +0100 > >> On 01.11.2016 16:35, David Miller wrote: >>> I have a really hard time accepting a "fix" that depends upon behavi

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

Hello, On 01.11.2016 17:39, Tom Herbert wrote: > On Tue, Nov 1, 2016 at 9:25 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 31.10.2016 20:25, Tom Herbert wrote: >>> The normal hash for TCP or UDP using ECMP is over <protocol, srcIP, >>>

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On 01.11.2016 16:35, David Miller wrote: > I have a really hard time accepting a "fix" that depends upon behavior > that the Linux ipv6 stack doesn't even have. We actually support this feature: commit df3687ffc6653e4d32168338b4dee20c164ed7c9 Author: Florent Fourcot

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On 31.10.2016 20:25, Tom Herbert wrote: > The normal hash for TCP or UDP using ECMP is over dstIP, srcPort, dstPort>. For an ICMP packet ECMP would most likely be > done over . There really is no way to ensure > that an ICMP packet will follow the same

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

Hi Thomas, On 01.11.2016 01:37, Thomas Graf wrote: > {Open question: > Tom brought up the question on whether it is safe to modify the packet > in artbirary ways before dst_output(). This is the equivalent to a raw > socket injecting illegal headers. This v2 currently assumes that >

Re: Let's do P4

On 31.10.2016 18:12, Jiri Pirko wrote: >> > >> >In the naive implementation only pipelines that map 1:1 will work. Maybe >> >this is what Alexei is noticing? > P4 is ment to program programable hw, not fixed pipeline. Is it realistic to assume that future hardware might be programmed with a

Re: [PATCH net-next 0/5] Route ICMPv6 errors with the flow when ECMP in use

Hi, On 27.10.2016 17:23, David Miller wrote: > From: Jakub Sitnicki > Date: Mon, 24 Oct 2016 11:28:47 +0200 > >> However, for it to work IPv6 flow labels have to be same in both >> directions (i.e. reflected) or need to be chosen in a manner that >> ensures that the flow going

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

; > Signed-off-by: Jakub Sitnicki <j...@redhat.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net-next 4/5] ipv6: Compute multipath hash for sent ICMP errors from offending packet

on receive side, when forwarding ICMP errors. > > Signed-off-by: Jakub Sitnicki <j...@redhat.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net-next 3/5] ipv6: Use multipath hash from flow info if available

at triggered the error. > > Signed-off-by: Jakub Sitnicki <j...@redhat.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net-next 2/5] net: Extend struct flowi6 with multipath hash

we would > like to make a routing decision based on the flow identifying the > offending IPv6 datagram that triggered the error, rather than the flow > of the ICMP error itself. > > Signed-off-by: Jakub Sitnicki <j...@redhat.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH net] net: add recursion limit to GRO

Hi, On Mon, Oct 10, 2016, at 16:03, Eric Dumazet wrote: > On Mon, 2016-10-10 at 15:43 +0200, Sabrina Dubroca wrote: > > Currently, GRO can do unlimited recursion through the gro_receive > > handlers. This was fixed for tunneling protocols by limiting tunnel GRO > > to one level with encap_mark,

Re: [PATCH] ipv6 addrconf: implement RFC7559 router solicitation backoff

Hello, On Wed, Sep 28, 2016, at 08:57, Maciej Żenczykowski wrote: > From: Maciej Żenczykowski > > This implements: > https://tools.ietf.org/html/rfc7559 > > Backoff is performed according to RFC3315 section 14: > https://tools.ietf.org/html/rfc3315#section-14 > > We allow

Re: kernel BUG at net/unix/garbage.c:149!"

On Tue, Sep 27, 2016, at 16:16, Nikolay Borisov wrote: > Dave, > > What's the status of https://patchwork.ozlabs.org/patch/664062/ , is > this going to be picked up ? Not sure if we actually fix a bug with this. Miklos could you maybe enhance the changelog then? Thanks, Hannes

Re: [PATCH v4 5/7] ipv6 addrconf: implement RFC7559 router solicitation backoff

[cc Vishwanath Pai] On 27.09.2016 11:42, Maciej Żenczykowski wrote: >> Please just use do_div here and go back to the first version of the >> patch. Variable names could be more aligned with the RFC maybe? > > So I tried: > > static inline s32 rfc3315_s14_backoff_init(s32 irt) > { >/*

Re: [PATCH v4 5/7] ipv6 addrconf: implement RFC7559 router solicitation backoff

On 27.09.2016 11:42, Maciej Żenczykowski wrote: >> Please just use do_div here and go back to the first version of the >> patch. Variable names could be more aligned with the RFC maybe? > > So I tried: > > static inline s32 rfc3315_s14_backoff_init(s32 irt) > { >/* multiply 'initial

Re: [PATCH v4 4/7] ipv6 addrconf: add new sysctl 'router_solicitation_max_interval'

On 27.09.2016 04:30, Maciej Żenczykowski wrote: >> Is seconds granular enough? > > The only reason why one would ever want to go into fractions of > seconds would be some sort of unittesting with very low delays. > > In any normal environment the max is going to be tens if not hundreds > or

Re: [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions

On 26.09.2016 16:53, Daniel Borkmann wrote: > On 09/26/2016 04:43 PM, Hannes Frederic Sowa wrote: >> On 26.09.2016 03:35, Florian Westphal wrote: >>> Jamal Hadi Salim <j...@mojatatu.com> wrote: >>>> On 16-09-25 02:31 PM, Florian Westphal wrote: >>>

Re: [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions

On 26.09.2016 03:35, Florian Westphal wrote: > Jamal Hadi Salim wrote: >> On 16-09-25 02:31 PM, Florian Westphal wrote: >>> Shmulik Ladkani wrote: We can later address any loop-detection improvements in mirred. WDYT? >>> >>> You can address

Re: [PATCH v4 4/7] ipv6 addrconf: add new sysctl 'router_solicitation_max_interval'

On 25.09.2016 13:03, Maciej Żenczykowski wrote: > + .procname = "router_solicitation_max_interval", > + .data = _devconf.rtr_solicit_max_interval, > + .maxlen = sizeof(int), > + .mode = 0644, > +

Re: [PATCH v4 5/7] ipv6 addrconf: implement RFC7559 router solicitation backoff

On 25.09.2016 13:03, Maciej Żenczykowski wrote: > +static inline s32 rfc3315_s14_backoff_init(s32 initial) > +{ > + u32 r = (9 << 20) / 10 + (prandom_u32() % ((2 << 20) / 10 + 1)); ^ > + s32 v = initial * (u64)r >> 20; /* ~ multiply by 0.9 .. 1.1 */ > + return v; > +} > + >

Re: [PATCH net] net: rtnl_register in net_ns_init need rtnl_lock

On Thu, Sep 22, 2016, at 19:20, Cong Wang wrote: > > I don't think it is a big issue but wanted the writes to the > > rtnl_msg_handlers array to be strictly serialized. I was working on > > adding this to other places, too. Maybe better for net-next even? > > But they are called during boot, why

Re: [PATCH net] net: rtnl_register in net_ns_init need rtnl_lock

On 22.09.2016 15:03, Eric Dumazet wrote: > On Thu, 2016-09-22 at 13:03 +0200, Hannes Frederic Sowa wrote: >> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> >> --- >> net/core/net_namespace.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >

[PATCH net] net: rtnl_register in net_ns_init need rtnl_lock

Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/core/net_namespace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c index 2c2eb1b629b11d..a2ace299f28355 100644 --- a/net/core/net_namespace.c +++ b/ne

Re: [PATCH net-next V2] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On 21.09.2016 18:14, Alexei Starovoitov wrote: > On Wed, Sep 21, 2016 at 12:10:55PM +0200, Hannes Frederic Sowa wrote: >> On 20.09.2016 20:57, Sowmini Varadhan wrote: >>> The vxlan header may not be aligned to 4 bytes in >>> vxlan_build_skb (e.g., for MLD packets). This

Re: [PATCH net-next V2] net/vxlan: Avoid unaligned access in vxlan_build_skb()

ed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> Performance wise this should only affect code generation for archs where it matters anyway. Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks, Hannes

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On 20.09.2016 16:27, Sowmini Varadhan wrote: > The vxlan header is at offset (14 + 20 + 8) into the packet, > so the vxh is not aligned in vxlan_build_skb. Use [get/put]_unaligned > functions to modify flags and vni field in the vxh. > > Signed-off-by: Sowmini Varadhan

Re: [PATCH] net: ipv6: Disable forwarding per interface via sysctl

On 16.09.2016 15:39, Eric Dumazet wrote: > On Fri, 2016-09-16 at 13:47 +0100, Mike Manning wrote: >> Disabling forwarding per interface via sysctl continues to allow >> forwarding. This is contrary to the sysctl documentation stating that >> the forwarding sysctl is per interface, whereas

Re: icmpv6: issue with routing table entries from link local addresses

On 13.09.2016 04:03, Sowmini Varadhan wrote: > On Mon, Sep 12, 2016 at 1:26 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> Hello, >> >> On 12.09.2016 16:27, Andreas Hübner wrote: > >>> >>> I have the following setup: >>&g

Re: icmpv6: issue with routing table entries from link local addresses

Hello, On 12.09.2016 16:27, Andreas Hübner wrote: > Hi, > > I'm currently debugging a potential issue with the icmpv6 stack and > hopefully this is the correct place to ask. (Was actually looking for a > more specific list, but didn't find anything. Please point me to a more > apropriate list if

Re: enable/disable temporary IPv6 per prefix

On 11.09.2016 09:29, Oliver Mangold wrote: > Hi, > > I have a question as a relatively new user to IPv6. I am wondering if it > is currently possible to enable/disable the usage of temporary addresses > on a per-prefix basis. My current understanding is that the feature is > enabled by the the

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

On Tue, Sep 6, 2016, at 17:49, Jiri Pirko wrote: > Tue, Sep 06, 2016 at 05:11:11PM CEST, d...@cumulusnetworks.com wrote: > >On 9/6/16 8:44 AM, Jiri Pirko wrote: > >> Tue, Sep 06, 2016 at 04:32:12PM CEST, d...@cumulusnetworks.com wrote: > >>> On 9/6/16 6:01 AM, Jiri Pirko wrote: > From: Jiri

Re: 答复: [PATCH] ipv6: addrconf: fix dev refcont leak when DAD failed

On 05.09.2016 13:54, weiyongjun (A) wrote: > On 05.09.2016 10:06, Wei Yongjun wrote: In general, when DAD detected IPv6 duplicate address, ifp->state will be set to INET6_IFADDR_STATE_ERRDAD and DAD is stopped by a delayed work, the call tree should be like this:

Re: [PATCH] ipv6: addrconf: fix dev refcont leak when DAD failed

On 05.09.2016 10:06, Wei Yongjun wrote: > In general, when DAD detected IPv6 duplicate address, ifp->state > will be set to INET6_IFADDR_STATE_ERRDAD and DAD is stopped by a > delayed work, the call tree should be like this: > > ndisc_recv_ns > -> addrconf_dad_failure<- missing ifp put

Re: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

gt; patch obviously touches the same code that the revert in 1/2 does. > > So this way the series ends up being "go back to the original code with > the original deadlock, and then fix that original deadlock by splitting > the bind lock". Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH 2/2] af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'

On 02.09.2016 21:15, David Miller wrote: > From: Linus Torvalds > Date: Fri, 2 Sep 2016 11:17:18 -0700 > >> Oh, this was missing a >> >> Reported-and-tested-by: CAI Qian >> >> who found the new deadlock. >> >> There's now *another* lockdep

Re: [PATCH iproute] iptuntap: show processes using tuntap interface

On 01.09.2016 18:06, Stephen Hemminger wrote: > On Wed, 24 Aug 2016 20:08:25 +0200 > Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > >> Show which processes are using which tun/tap devices, e.g.: >> >> $ ip -d tuntap >> tun0: tun >> At

Re: [PATCH] softirq: let ksoftirqd do its job

On 01.09.2016 14:57, Eric Dumazet wrote: > On Thu, 2016-09-01 at 14:38 +0200, Jesper Dangaard Brouer wrote: > >> Correction, on the server-under-test, I'm actually running RHEL7.2 >> >> >>> How do I verify/check if I have enabled a cpu-cgroup? >> >> Hannes says I can look in "/proc/self/cgroup"

Re: [PATCH] softirq: let ksoftirqd do its job

On 31.08.2016 22:42, Eric Dumazet wrote: > On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer wrote: > >> I can confirm the improvement of approx 900Kpps (no wonder people have >> been complaining about DoS against UDP/DNS servers). >> >> BUT during my extensive testing, of this patch, I

Re: [PATCH] softirq: let ksoftirqd do its job

huge improvement in DOS situation. (Note that more packets are now > dropped by the NIC itself, since the BH handlers get less cpu cycles to > drain RX ring buffer) > > Since the load runs in well identified threads context, an admin can > more easily tune process scheduling param

Re: [PATCH] softirq: let ksoftirqd do its job

On 01.09.2016 13:02, Jesper Dangaard Brouer wrote: > On Wed, 31 Aug 2016 23:51:16 +0200 > Jesper Dangaard Brouer wrote: > >> On Wed, 31 Aug 2016 13:42:30 -0700 >> Eric Dumazet wrote: >> >>> On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer

Re: kernel BUG at net/unix/garbage.c:149!"

On 30.08.2016 11:18, Miklos Szeredi wrote: > On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote: >> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote: > >> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight | >> grep counter |

Re: kernel BUG at net/unix/garbage.c:149!"

On 25.08.2016 01:30, Nikolay Borisov wrote: > On Thu, Aug 25, 2016 at 12:40 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 24.08.2016 16:24, Nikolay Borisov wrote: > [SNIP] >> >> One commit which could hav

Re: [PATCH net-next] net: batch calls to flush_all_backlogs()

1.302137465 seconds time elapsed > > After patch: > > perf stat -e context-switches -a rmmod dummy > > Performance counter stats for 'system wide': > >225,523 context-switches > >0.721623566 seconds time elapsed Cool demonstration! :} Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH iproute] iptuntap: show processes using tuntap interface

On 25.08.2016 17:44, Stephen Hemminger wrote: > On Wed, 24 Aug 2016 20:08:25 +0200 > Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > >> Show which processes are using which tun/tap devices, e.g.: >> >> $ ip -d tuntap >> tun0: tun >> At

Re: kernel BUG at net/unix/garbage.c:149!"

On 24.08.2016 16:24, Nikolay Borisov wrote: > Hello, > > I hit the following BUG: > > [1851513.239831] [ cut here ] > [1851513.240079] kernel BUG at net/unix/garbage.c:149! > [1851513.240313] invalid opcode: [#1] SMP > [1851513.248320] CPU: 37 PID: 11683 Comm:

Re: CVE-2014-9900 fix is not upstream

On 24.08.2016 16:03, Lennart Sorensen wrote: > On Tue, Aug 23, 2016 at 10:25:45PM +0100, Al Viro wrote: >> Sadly, sizeof is what we use when copying that sucker to userland. So these >> padding bits in the end would've leaked, true enough, and the case is >> somewhat >> weaker. And any normal

[PATCH iproute] iptuntap: show processes using tuntap interface

Show which processes are using which tun/tap devices, e.g.: $ ip -d tuntap tun0: tun Attached to processes: vpnc(9531) vnet0: tap vnet_hdr Attached to processes: qemu-system-x86(10442) virbr0-nic: tap UNKNOWN_FLAGS:800 Attached to processes: Signed-off-by: Hannes Frederic

Re: [PATCH] net: ip_finish_output_gso: Allow fragmenting segments of tunneled skbs if their DF is unset

do set IP_DF, will not go to fragmentation of segments. > This preserves behavior of ip_gre in (the default) pmtudisc mode. > > Fixes: b8247f095e ("net: ip_finish_output_gso: If skb_gso_network_seglen > exceeds MTU, allow segmentation for local udp tunneled skbs") > Reported-

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

On 19.08.2016 09:26, Shmulik Ladkani wrote: > On Mon, 15 Aug 2016 14:16:39 +0300 Shmulik Ladkani > wrote: >> On Fri, 12 Aug 2016 13:11:50 +0200, han...@stressinduktion.org wrote: >>> I really would not like to see this expanded to gre and other protocols. >>> All

Re: [PATCH] net: ipv6: Remove addresses for failures with strict DAD

On Wed, Aug 17, 2016, at 18:08, Mike Manning wrote: > On 08/17/2016 04:40 PM, Hannes Frederic Sowa wrote: > > On 17.08.2016 12:28, Mike Manning wrote: > >> +static void dev_disable_change(struct inet6_dev *idev); > >> > >> /* > >> *Configur

Re: [PATCH] net: ipv6: Remove addresses for failures with strict DAD

On 17.08.2016 12:28, Mike Manning wrote: > +static void dev_disable_change(struct inet6_dev *idev); > > /* > * Configured unicast address hash table > @@ -1945,6 +1946,12 @@ lock_errdad: > > pr_info("%s: IPv6 being disabled!\n", >

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

On 11.08.2016 21:41, Shmulik Ladkani wrote: > On Wed, 10 Aug 2016 17:35:11 -0700 (PDT) David Miller > wrote: >>> commit b8247f095edd ("net: ip_finish_output_gso: If skb_gso_network_seglen >>> exceeds MTU, allow segmentation for local udp tunneled skbs") >>> >>> Given: >>>

Re: [PATCH net] net: ipv6: Fix ping to link-local addresses.

On 09.08.2016 10:37, YOSHIFUJI Hideaki wrote: > > > Erik Kline wrote: >> On 9 August 2016 at 14:20, David Miller wrote: >>> From: Lorenzo Colitti >>> Date: Tue, 9 Aug 2016 10:00:25 +0900 >>> Note that pretty much every sendmsg codepath allows other

Re: [PATCH net] net: ipv6: Fix ping to link-local addresses.

On 08.08.2016 09:42, Lorenzo Colitti wrote: > ping_v6_sendmsg never sets flowi6_oif, so it is not possible to > ping an IPv6 address on a different interface. Instead, it sets > flowi6_iif, which is incorrect but harmless. Also, it returns an > error if a passed-in scope ID doesn't match

Re: IPIP tunnel with fixed TTL but no DF bit

Hello, On 04.08.2016 08:20, Alexander Heinlein wrote: > I would like to know why ip_tunnel_ioctl() enforces the DF bit whenever > the tunnel device has a fixed TTL set. The same restriction is enforced > by iproute2 (iptunnel.c and link_iptnl.c). > > Ideally I would like to use an IPIP tunnel

Re: [PATCH v2] net: neigh: disallow transition to NUD_STALE if lladdr is unchanged in neigh_update()

<hchun...@mail.ustc.edu.cn> > --- > v2: > - change title from "net: neigh: disallow state transition DELAY->STALE in >neigh_update()" > - remove "NUD_CONNECTED" condition instead of "NUD_CONNECTED | NUD_DELAY" > - remove "NEIGH_UPDATE_F_WEAK_OVERRIDE" condition Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks!

Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()

_update(struct neighbour *neigh, 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 <han...@stressinduktion.org> Thanks, Hannes

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

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 > gso and non-gso cases), which

Re: [PATCH 1/2] net/ipv4: Introduce IPSKB_FRAG_SEGS bit to inet_skb_parm.flags

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 <han...@stre

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

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

<    1   2   3   4   5   6   7   8   9   >