Re: [PATCH nf-next] netfilter: xt_CHECKSUM: avoid bad offload warnings on GSO packets

Davide Caratti wrote: > Small nit: may I suggest you to call skb_csum_hwoffload_help() instead of > skb_checksum_help(), so that we avoid corrupting SCTP packets in case they > hit xt_CHECKSUM target? Alternatively we could restrict the target to udp only. AFAIU the only

Re: [PATCH nf-next] netfilter: xt_CHECKSUM: avoid bad offload warnings on GSO packets

Michal Kubecek wrote: > When --checksum_fill action is applied to a GSO packet, checksum_tg() calls > skb_checksum_help() which is only meant to be applied to non-GSO packets so > that it issues a warning. > > This can be easily triggered by using e.g. > > iptables -t mangle

Re: [PATCH net-next] dsa: remove unused net_device arg from handlers

Andrew Lunn <and...@lunn.ch> wrote: > On Thu, Aug 17, 2017 at 04:47:00PM +0200, Florian Westphal wrote: > > compile tested only, but saw no warnings/errors with > > allmodconfig build. > > > > static int dsa_switch_rcv(struct sk_

[PATCH net-next] dsa: remove unused net_device arg from handlers

compile tested only, but saw no warnings/errors with allmodconfig build. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/dsa.h | 6 ++ net/dsa/dsa.c | 4 ++-- net/dsa/tag_brcm.c| 3 +-- net/dsa/tag_dsa.c | 3 +-- net/dsa/tag_edsa.c| 3 +-- n

[PATCH net-next 1/4] selftests: add 'ip get' to rtnetlink.sh

exercise ip/ip6 RTM_GETROUTE doit() callpath. Signed-off-by: Florian Westphal <f...@strlen.de> --- tools/testing/selftests/net/rtnetlink.sh | 32 1 file changed, 32 insertions(+) diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/sel

[PATCH net-next 0/4] inet: make RTM_GETROUTE work without rtnl

ipv4 getroute doesn't assume rtnl lock is held anymore, also make this true for ipv6, then switch both to DOIT_UNLOCKED.

[PATCH net-next 2/4] ipv6: route: make rtm_getroute not assume rtnl is locked

__dev_get_by_index assumes RTNL is held, use _rcu version instead. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv6/route.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 035762fed07d..ec694fdb8cc5 100644 ---

[PATCH net-next 3/4] ipv6: route: set ipv6 RTM_GETROUTE to not use rtnl

Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv6/route.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index ec694fdb8cc5..3c15f005c90e 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -4112,7 +4112,8 @@ int

[PATCH net-next 4/4] ipv4: route: set ipv4 RTM_GETROUTE to not use rtnl

Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv4/route.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 6810d2076b1b..618bbe1405fc 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -3073,7 +3073,8 @@ int

Re: general protection fault in fib_dump_info

idaifish wrote: > Syzkaller hit 'general protection fault in fib_dump_info' bug on > commit 4.13-rc5.. CC Roopa > Guilty file: net/ipv4/fib_semantics.c > > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN >

Re: [PATCH net] ipv4: route: fix inet_rtm_getroute induced crash

David Ahern <dsah...@gmail.com> wrote: > On 8/13/17 4:52 PM, Florian Westphal wrote: > > "ip route get $daddr iif eth0 from $saddr" causes: > > BUG: KASAN: use-after-free in ip_route_input_rcu+0x1535/0x1b50 > > Call Trace: > > ip_route_input_rcu+0x

[PATCH net] ipv4: route: fix inet_rtm_getroute induced crash

;done > /dev/null & ... and saw no crash or memory leak. Cc: Roopa Prabhu <ro...@cumulusnetworks.com> Cc: David Ahern <dsah...@gmail.com> Fixes: ba52d61e0ff ("ipv4: route: restore skb_dst_set in inet_rtm_getroute") Signed-off-by: Florian Westphal <f...@strlen.de> --- ne

Re: [PATCH] net/sched: reset block pointer in tcf_block_put()

Cong Wang wrote: > On Thu, Aug 10, 2017 at 2:31 AM, Konstantin Khlebnikov > wrote: > > In previous API tcf_destroy_chain() could be called several times and > > some schedulers like hfsc and atm use that. In new API tcf_block_put() > > frees

[PATCH net-next 5/6] rtnetlink: fallback to UNSPEC if current family has no doit callback

We need to use PF_UNSPEC in case the requested family has no doit callback, otherwise this now fails with EOPNOTSUPP instead of running the unspec doit callback, as before. Fixes: 6853dd488119 ("rtnetlink: protect handler table with rcu") Signed-off-by: Florian Westphal <f...@strlen

[PATCH net-next 6/6] selftests: add rtnetlink test script

add a simple script to exercise some rtnetlink call paths, so KASAN, lockdep etc. can yell at developer before patches are sent upstream. This can be extended to also cover bond, team, vrf and the like. Signed-off-by: Florian Westphal <f...@strlen.de> --- This test crashes the kerne

[PATCH net-next 4/6] rtnetlink: init handler refcounts to 1

l test robot <fengguang...@intel.com> Signed-off-by: Florian Westphal <f...@strlen.de> --- net/core/rtnetlink.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 087f2434813a..59eda6952bc9 100644 --- a/net/core/rtnetli

[PATCH net-next 0/6] rtnetlink: fix initial rtnl pushdown fallout

This series fixes various bugs and splats reported since the allow-handler-to-run-with-no-rtnl series went in. Last patch adds a script that can be used to add further tests in case more bugs are reported. In case you prefer reverting the original series instead of fixing fallout I can resend

[PATCH net-next 2/6] rtnetlink: do not use RTM_GETLINK directly

checking family index. vs handler array size. Fixes: e1fa6d216dd ("rtnetlink: call rtnl_calcit directly") Signed-off-by: Florian Westphal <f...@strlen.de> --- net/core/rtnetlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/rtnetlink.c b/net/

[PATCH net-next 3/6] rtnetlink: switch rtnl_link_get_slave_info_data_size to rcu

ndler table with rcu") Reported-by: David Ahern <dsah...@gmail.com> Signed-off-by: Florian Westphal <f...@strlen.de> --- net/core/rtnetlink.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index a9b5

[PATCH net-next 1/6] rtnetlink: use rcu_dereference_raw to silence rcu splat

years or so. Fixes: 6853dd4881 ("rtnetlink: protect handler table with rcu") Reported-by: Ido Schimmel <ido...@idosch.org> Signed-off-by: Florian Westphal <f...@strlen.de> --- net/core/rtnetlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/

Re: [PATCH v2 net-next 0/7] rtnetlink: allow selected handlers to run without rtnl

David Ahern wrote: > On 8/9/17 6:21 PM, David Miller wrote: > > > > Ok series applied, let's see where this goes :-) > > > > 1 hour in, 1 problem reported Its even worse. Would you rather see a revert? I'm sure that you are aware that the widespread rtnl usage is a

[PATCH v2 net-next 2/7] rtnetlink: make rtnl_register accept a flags parameter

This change allows us to later indicate to rtnetlink core that certain doit functions should be called without acquiring rtnl_mutex. This change should have no effect, we simply replace the last (now unused) calcit argument with the new flag. Signed-off-by: Florian Westphal <f...@strlen

[PATCH v2 net-next 7/7] net: call newid/getid without rtnl mutex held

Both functions take nsid_lock and don't rely on rtnl lock. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- No changes since v1. net/core/net_namespace.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

[PATCH v2 net-next 6/7] rtnetlink: add RTNL_FLAG_DOIT_UNLOCKED

Allow callers to tell rtnetlink core that its doit callback should be invoked without holding rtnl mutex. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- change since v1: don't make ipv6 route rtnl handlers lockle

[PATCH v2 net-next 5/7] rtnetlink: protect handler table with rcu

Note that netlink dumps still acquire rtnl mutex via the netlink dump infrastructure. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- No changes since v1. net/core/rtnet

[PATCH v2 net-next 4/7] rtnetlink: small rtnl lock pushdown

/unlock/dump/lock/unlock rtnl sequence becomes rcu lock/rcu unlock/dump). Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- No changes since v1. net/core/rtnetlink.c | 19 +-- 1 file changed, 13 inse

[PATCH v2 net-next 3/7] rtnetlink: add reference counting to prevent module unload while dump is in progress

* bump refcount * release mutex * start the dump ... and make unregister_all remove the callbacks (no new dumps possible) and then wait until refcount is 0. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- No changes si

[PATCH v2 net-next 0/7] rtnetlink: allow selected handlers to run without rtnl

Changes since v1: In patch 6, don't make ipv6 route handlers lockless, they all have assumptions on rtnl being held. Other patches are unchanged. The RTNL mutex is used to serialize both rtnetlink calls and dump requests. Its also used to protect other things such as the list of current net

[PATCH v2 net-next 1/7] rtnetlink: call rtnl_calcit directly

o allocate space for the function pointer for all the other families. A followup patch will drop the calcit function pointer from the rtnl_link callback structure. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- No c

Re: [PATCH net-next 0/7] rtnetlink: allow to run selected handlers without rtnl

David Miller <da...@davemloft.net> wrote: > From: Florian Westphal <f...@strlen.de> > Date: Tue, 8 Aug 2017 18:02:29 +0200 > > > Unfortunately RTNL mutex is a performance issue, e.g. a cpu adding > > an ip address prevents other cpus from seemingly unrel

[PATCH net-next 3/7] rtnetlink: add reference counting to prevent module unload while dump is in progress

* bump refcount * release mutex * start the dump ... and make unregister_all remove the callbacks (no new dumps possible) and then wait until refcount is 0. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/core/rtne

[PATCH net-next 2/7] rtnetlink: make rtnl_register accept a flags parameter

This change allows us to later indicate to rtnetlink core that certain doit functions should be called without acquiring rtnl_mutex. This change should have no effect, we simply replace the last (now unused) calcit argument with the new flag. Signed-off-by: Florian Westphal <f...@strlen

[PATCH net-next 4/7] rtnetlink: small rtnl lock pushdown

/unlock/dump/lock/unlock rtnl sequence becomes rcu lock/rcu unlock/dump). Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/core/rtnetlink.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-)

[PATCH net-next 6/7] rtnetlink: add and use RTNL_FLAG_DOIT_UNLOCKED

Allow callers to tell rtnetlink core that its doit callback should be invoked without holding rtnl mutex. Make ipv6 the first user. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/rtnetlink.h | 4 ++

[PATCH net-next 5/7] rtnetlink: protect handler table with rcu

Note that netlink dumps still acquire rtnl mutex via the netlink dump infrastructure. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/core/rtnetlink.c | 121 +++ 1

[PATCH net-next 7/7] net: call newid/getid without rtnl mutex held

Both functions take nsid_lock and don't reply on rtnl lock. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/core/net_namespace.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --gi

[PATCH net-next 1/7] rtnetlink: call rtnl_calcit directly

o allocate space for the function pointer for all the other families. A followup patch will drop the calcit function pointer from the rtnl_link callback structure. Signed-off-by: Florian Westphal <f...@strlen.de> Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net

[PATCH net-next 0/7] rtnetlink: allow to run selected handlers without rtnl

The RTNL mutex is used to serialize both rtnetlink calls and dump requests. Its also used to protect other things such as the list of current netns. Unfortunately RTNL mutex is a performance issue, e.g. a cpu adding an ip address prevents other cpus from seemingly unrelated tasks such as dumping

[PATCH ipsec-next] xfrm: check that cached bundle is still valid

lso verify the path is still valid. Fixes: ec30d78c14a813 ("xfrm: add xdst pcpu cache") Reported-by: Ayham Masood <ayh...@mellanox.com> Tested-by: Ilan Tayari <il...@mellanox.com> Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 3 ++- 1 f

Re: XFRM pcpu cache issue

Ilan Tayari wrote: > I debugged a little the regression I told you about the other day... > > Steps and Symptoms: > 1. Set up a host-to-host IPSec tunnel (or transport, doesn't matter) > 2. Ping over IPSec, or do something to populate the pcpu cache > 3. Join a MC group, then

Re: [RFC 0/1] tcp: constify congestion_ops

Stephen Hemminger wrote: > I wonder if restricting congestion control choices is still necessary? > It seems like being overly paranoid, and better enforced by having a more > limited kernel config, seccomp or other mechanism. Agree, I think it can be removed.

[PATCH net-next 2/6] tcp: reindent two spots after prequeue removal

These two branches are now always true, remove the conditional. objdiff shows no changes. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv4/tcp_input.c | 50 +++--- 1 file changed, 23 insertions(+), 27 deletions(-) diff --git a/ne

[PATCH net-next 4/6] tcp: remove header prediction

Like prequeue, I am not sure this is overly useful nowadays. If we receive a train of packets, GRO will aggregate them if the headers are the same (HP predates GRO by several years) so we don't get a per-packet benefit, only a per-aggregated-packet one. Signed-off-by: Florian Westphal &l

[PATCH net-next 1/6] tcp: remove prequeue support

using netperf between two physical hosts with ixgbe interfaces. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/linux/tcp.h | 9 include/net/tcp.h| 11 - net/ipv4/tcp.c | 105 --- net/ipv4/tcp_i

[PATCH net-next 5/6] tcp: remove CA_ACK_SLOWPATH

re-indent tcp_ack, and remove CA_ACK_SLOWPATH; it is always set now. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/tcp.h | 5 ++--- net/ipv4/tcp_input.c| 35 --- net/ipv4/tcp_westwood.c | 31 --- 3

[PATCH net-next 6/6] tcp: remove unused mib counters

was used by tcp prequeue and header prediction. TCPFORWARDRETRANS use was removed in january. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/uapi/linux/snmp.h | 9 - net/ipv4/proc.c | 9 - 2 files changed, 18 deletions(-) diff --git a/include/uapi

[net-next 0/6] tcp: remove prequeue and header prediction

During a hallway discussion with Eric Dumazet at Netdev 1.2 in Tokyo some maybe-not-so-useful-anymore TCP stack features came up, among these header prediction and prequeueing. In brief, TCP prequeue assumes a single-process-blocking-read design, which is not that common anymore. The most

[PATCH net-next 3/6] tcp: remove low_latency sysctl

Was only checked by the removed prequeue code. Signed-off-by: Florian Westphal <f...@strlen.de> --- Documentation/networking/ip-sysctl.txt | 7 +-- include/net/tcp.h | 1 - net/ipv4/sysctl_net_ipv4.c | 3 +++ net/ipv4/tcp_ipv4.c| 2

Re: [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters

Julia Lawall wrote: > > I think we can indeed constify these completely after making > > 'nla_size' set at compile time. > > > > I'll send a simple attempt to make it so for l3proto soon. > > There is another issue with respect to nf_ct_l3proto_unregister. This > calls

Re: [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters

change is useful from a documentation point of view, and can > possibly facilitate making some nf_conntrack_l3/4proto structures const > subsequently. > > Done with the help of Coccinelle. > > Some spacing adjusted to fit within 80 characters. Acked-by: Florian Westphal <f...@strlen

Re: [PATCH 0/2] constify nf_hook_ops structures

Julia Lawall <julia.law...@lip6.fr> wrote: > On Sat, 29 Jul 2017, Florian Westphal wrote: > > From a quick glance I don't see why we can't e.g. constify > > nf_conntrack_l3/4_proto too. It is not going to be as simple > > as just placing const everywhere, but I see no

Re: [PATCH 0/2] constify nf_hook_ops structures

Julia Lawall <julia.law...@lip6.fr> wrote: > > > On Sat, 29 Jul 2017, Florian Westphal wrote: > > > Julia Lawall <julia.law...@lip6.fr> wrote: > > > The nf_hook_ops structure is only passed as the second argument to > > > nf_register_n

Re: [PATCH 0/2] constify nf_hook_ops structures

Julia Lawall wrote: > The nf_hook_ops structure is only passed as the second argument to > nf_register_net_hook or nf_unregister_net_hook, both of which are > declared as const. Thus the nf_hook_ops structure itself can be > const. Right, also see

[RFC PATCH net-next 3/6] tcp: remove low_latency sysctl

this option was used by the removed prequeue code, it has no effect anymore. Signed-off-by: Florian Westphal <f...@strlen.de> --- Documentation/networking/ip-sysctl.txt | 7 +-- include/net/tcp.h | 1 - net/ipv4/sysctl_net_ipv4.c | 3 +++ net/ipv4/tcp_

[RFC PATCH net-next 2/6] tcp: reindent two spots after prequeue removal

These two branches are now always true, remove the conditional. objdiff shows no changes. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv4/tcp_input.c | 50 +++--- 1 file changed, 23 insertions(+), 27 deletions(-) diff --git a/ne

[RFC PATCH net-next 5/6] tcp: remove CA_ACK_SLOWPATH

re-indent tcp_ack, and remove CA_ACK_SLOWPATH; it is always set now. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/tcp.h | 5 ++--- net/ipv4/tcp_input.c| 35 --- net/ipv4/tcp_westwood.c | 31 --- 3

[RFC PATCH net-next 4/6] tcp: remove header prediction

Like prequeue, I am not sure this is overly useful nowadays. If we receive a train of packets, GRO will aggregate them if the headers are the same (HP predates GRO by several years) so we don't get a per-packet benefit, only a per-aggregated-packet one. Signed-off-by: Florian Westphal &l

[RFC PATCH net-next 6/6] tcp: remove unused mib counters

was used by tcp prequeue, TCPFORWARDRETRANS use was removed in january. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/uapi/linux/snmp.h | 8 net/ipv4/proc.c | 8 2 files changed, 16 deletions(-) diff --git a/include/uapi/linux/snmp.h b/includ

[RFC net-next 0/6] tcp: remove prequeue and header prediction

data on the retransmit queue. Header prediction is also less useful nowadays. For packet trains, GRO will aggregate packets so we do not get a per-packet benefit. Header prediction will also break down with light packet loss due to SACK. So, In short: What do others think? Florian Westphal (6

[RFC PATCH net-next 1/6] tcp: remove prequeue support

no changes when using netperf between two physical hosts with ixgbe interfaces. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/linux/tcp.h | 9 include/net/tcp.h| 11 - net/ipv4/tcp.c | 105 --- ne

Re: nf_nat_pptp 4.12.3 kernel lockup/reboot

Florian Westphal <f...@strlen.de> wrote: > Denys Fedoryshchenko <nuclear...@nuclearcat.com> wrote: > > Hi, > > > > I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling > > approx 2gbps of pppoe users traffic) and noticed that afte

Re: nf_nat_pptp 4.12.3 kernel lockup/reboot

Denys Fedoryshchenko wrote: > Hi, > > I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling > approx 2gbps of pppoe users traffic) and noticed that after while server > rebooting(i have set reboot on panic and etc). > I can't run serial console,

[PATCH net-next] skbuff: re-add check for NULL skb->head in kfree_skb path

memory and remove the special handling in netlink destructor. Reported-by: kernel test robot <fengguang...@intel.com> Fixes: 06dc75ab06943 ("net: Revert "net: add function to allocate sk_buff head without data area") Signed-off-by: Florian Westphal <f...@strlen.de> ---

Re: [RFC 1/2] net-next: add a dma_desc element to struct skb_shared_info

John Crispin wrote: > When the flow offloading engine forwards a packet to the DMA it will send > additional info to the sw path. this includes > * physical switch port > * internal flow hash - this is required to populate the correct flow table > entry > * ppe state - this

Re: [PATCH 0/5] Netfilter fixes for net

David Miller wrote: > What about that change Eric Dumazet was talking about with Florian > that stopped instantiating conntrack by default in new namespaces? Seems more appropriate for -next. If you prefer net instead, let me know and I'll get to work.

[PATCH net-next] net: Revert "net: add function to allocate sk_buff head without data area"

It was added for netlink mmap tx, there are no callers in the tree. The commit also added a check for skb->head != NULL in kfree_skb path, remove that too -- all skbs ought to have skb->head set. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/linux/skbuff.h | 6

[PATCH net-next 02/10] vti: revert flush x-netns xfrm cache when vti interface is removed

flow cache is removed in next commit. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv4/ip_vti.c | 31 --- net/ipv6/ip6_vti.c | 31 --- 2 files changed, 62 deletions(-) diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c

[PATCH net-next 09/10] xfrm: remove flow cache

After rcu conversions performance degradation in forward tests isn't that noticeable anymore. See next patch for some numbers. A followup patcg could then also remove genid from the policies as we do not cache bundles anymore. Signed-off-by: Florian Westphal <f...@strlen.de> --- inclu

[PATCH net-next 10/10] xfrm: add xdst pcpu cache

alue is average over ten iterations. 'Flow cache' is 'net-next', 'No flow cache' is net-next plus this series but without this patch. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/xfrm.h | 1 + net/xfrm/xfrm_device.c | 2 + net/xfr

[PATCH net-next 04/10] xfrm_policy: bypass flow_cache_lookup

Instead of consulting flow cache, call the xfrm bundle/policy lookup functions directly. This pretends the flow cache had no entry. This helps to gradually remove flow cache integration, followup commit will remove the dead code that this change adds. Signed-off-by: Florian Westphal &l

[PATCH net-next 08/10] xfrm_policy: make xfrm_bundle_lookup return xfrm dst object

This allows to remove flow cache object embedded in struct xfrm_dst. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 28 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_po

[PATCH net-next 07/10] xfrm_policy: remove xfrm_policy_lookup

This removes the wrapper and renames the __xfrm_policy_lookup variant to get rid of another place that used flow cache objects. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 36 1 file changed, 4 insertions(+), 32 del

[PATCH net-next 05/10] xfrm_policy: remove always true/false branches

after previous change oldflo and xdst are always NULL. These branches were already removed by gcc, this doesn't change code. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 74 ++ 1 file changed, 14 insertions(

[PATCH net-next 0/10] xfrm: remove flow cache

After RCU-ification of ipsec packet path there are no major scalability issues anymore without flow cache. We still incur a performance hit, which comes mostly from the extra xfrm dst allocation/freeing. The last patch in the series adds a simple percpu cache to avoid the extra allocation if a

[PATCH net-next 03/10] net: xfrm: revert to lower xfrm dst gc limit

revert c386578f1cdb4dac230395 ("xfrm: Let the flowcache handle its size by default."). Once we remove flow cache, we don't have a flow cache limit anymore. We must not allow (virtually) unlimited allocations of xfrm dst entries. Revert back to the old xfrm dst gc limits. Signed-off-b

[PATCH net-next 06/10] xfrm_policy: kill flow to policy dir conversion

XFRM_POLICY_IN/OUT/FWD are identical to FLOW_DIR_*, so gcc already removed this function as its just returns the argument. Again, no code change. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 46 -- 1 file chan

[PATCH net-next 01/10] drivers: net: add missing interrupt.h include

these drivers use tasklets or irq apis, but don't include interrupt.h. Once flow cache is removed the implicit interrupt.h inclusion goes away which will break the build. Signed-off-by: Florian Westphal <f...@strlen.de> --- drivers/net/arcnet/arcdevice.h | 2 +- drive

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Richard Weinberger <rich...@nod.at> wrote: > Am 01.07.2017 um 12:35 schrieb Florian Westphal: > > The compare on removal is not needed afaics, and its also not used when > > doing lookup to begin with, so we can just recompute it? > > Isn't this a way too much

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Richard Weinberger <rich...@nod.at> wrote: > Florian, > > Am 30.06.2017 um 21:55 schrieb Florian Westphal: > >>> Why not use a hash of the address? > >> > >> Would also work. Or xor it with a random number. > >> > >>

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Richard Weinberger <rich...@nod.at> wrote: > Florian, > > Am 30.06.2017 um 21:35 schrieb Florian Westphal: > > Richard Weinberger <rich...@nod.at> wrote: > >> Hi! > >> > >> I noticed that nf_conntrack leaks kernel addresses, it uses the memor

Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID

Richard Weinberger wrote: > Hi! > > I noticed that nf_conntrack leaks kernel addresses, it uses the memory address > as identifier used for generating conntrack and expect ids.. > Since these ids are also visible to unprivileged users via network namespaces > I suggest reverting

Re: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache

Ilan Tayari wrote: > > -Original Message- > > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > > Subject: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache > > > > retain last used xfrm_dst in a pcpu cache. > > On next request, reuse this

[RFC net-next 7/9] xfrm_policy: make xfrm_bundle_lookup return xfrm dst object

This allows to remove flow cache object embedded in struct xfrm_dst. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 28 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_po

[RFC net-next 9/9] xfrm: add a small xdst pcpu cache

ne. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/xfrm.h | 1 + net/xfrm/xfrm_device.c | 1 + net/xfrm/xfrm_policy.c | 44 3 files changed, 46 insertions(+) diff --git a/include/net/xfrm.h b/include/net/xfrm.h index 9b85367529a4

[RFC net-next 8/9] xfrm: remove flow cache

After rcu conversions performance degradation in forward tests isn't that noticeable anymore. See next patch for some numbers. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/flow.h | 34 --- include/net/flowcache.h | 25 -- include/net/netns/

[RFC net-next 6/9] xfrm_policy: remove xfrm_policy_lookup

This removes the wrapper and renames the __xfrm_policy_lookup variant to get rid of another place that used flow cache objects. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 36 1 file changed, 4 insertions(+), 32 del

[RFC net-next 5/9] xfrm_policy: kill flow to policy dir conversion

XFRM_POLICY_IN/OUT/FWD are identical to FLOW_DIR_*, so gcc already removed this function as its just returns the argument. Again, no code change. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 46 -- 1 file chan

[RFC net-next 4/9] xfrm_policy: remove always true/false branches

after previous change oldflo and xdst are always NULL. These branches were already removed by gcc, this doesn't change code. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/xfrm/xfrm_policy.c | 74 ++ 1 file changed, 14 insertions(

[RFC net-next 3/9] xfrm_policy: bypass flow_cache_lookup

Instead of consulting flow cache, call the xfrm bundle/policy lookup functions directly. This pretends the flow cache had no entry. This helps to gradually remove flow cache integration, followup commit will remove the dead code that this change adds. Signed-off-by: Florian Westphal &l

[RFC ipsec-next] flow cache removal

Here is an updated version of the flow cache removal set. Changes since last iteration: - rebase - split removal into multiple gradual chunks to ease review - add a small pcpu xdst cache to reduce alloc/free overhead when subsequent packet can re-use previous xdst I did some sanity testing

[RFC net-next 1/9] vti: revert flush x-netns xfrm cache when vti interface is removed

flow cache is removed in next commit. Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv4/ip_vti.c | 31 --- net/ipv6/ip6_vti.c | 31 --- 2 files changed, 62 deletions(-) diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c

[RFC net-next 2/9] net: xfrm: revert to lower xfrm dst gc limit

revert c386578f1cdb4dac230395 ("xfrm: Let the flowcache handle its size by default."). Once we remove flow cache, we don't have a flow cache limit anymore. We must not allow (virtually) unlimited allocations of xfrm dst entries. Revert back to the old xfrm dst gc limits. Signed-off-b

Re: [PATCH net-next] netfilter: conntrack: add a new NF_CT_EXT_EXPAND extension

Lin Zhang wrote: > In the current conntrack extend code, if we want to add a new > extension, we must be add a new extension id and recompile kernel. > I think that is not be convenient for users, so i add a new extension named > NF_CT_EXT_EXPAND for supporting dynamic

Re: [PATCH nf-next] netns: add and use net_ns_barrier

Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Mon, Jun 12, 2017 at 11:16 PM, Florian Westphal <f...@strlen.de> wrote: > > Cong Wang <xiyou.wangc...@gmail.com> wrote: > >> On Thu, Jun 1, 2017 at 1:52 AM, Florian Westphal <f...@strlen.de> wrot

Re: [PATCH nf-next] netns: add and use net_ns_barrier

Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Thu, Jun 1, 2017 at 1:52 AM, Florian Westphal <f...@strlen.de> wrote: > > Joe described it nicely, problem is that after unload we may have > > conntracks that still have a nf_conn_help extension attached that >

Re: [PATCH v2] decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb

Mateusz Jurczyk wrote: > Verify that the length of the socket buffer is sufficient to cover the > nlmsghdr structure before accessing the nlh->nlmsg_len field for further > input sanitization. If the client only supplies 1-3 bytes of data in > sk_buff, then nlh->nlmsg_len

Re: [PATCH v4] net: don't call strlen on non-terminated string in dev_set_alias()

David Miller wrote: > From: Alexander Potapenko > Date: Tue, 6 Jun 2017 15:56:54 +0200 > > > KMSAN reported a use of uninitialized memory in dev_set_alias(), > > which was caused by calling strlcpy() (which in turn called strlen()) > > on the

Re: [PATCH nf-next] netns: add and use net_ns_barrier

David Laight <david.lai...@aculab.com> wrote: > From: Florian Westphal > > Sent: 30 May 2017 10:38 > > > > Quoting Joe Stringer: > > If a user loads nf_conntrack_ftp, sends FTP traffic through a network > > namespace, destroys that names

Re: [PATCH nf-next] netns: add and use net_ns_barrier

Eric W. Biederman <ebied...@xmission.com> wrote: > Florian Westphal <f...@strlen.de> writes: > > > Quoting Joe Stringer: > > If a user loads nf_conntrack_ftp, sends FTP traffic through a network > > namespace, destroys that namespace then unloads the FTP

[PATCH nf-next] netns: add and use net_ns_barrier

of these conntracks are unaffected. 6. helper module unload finishes 7. netns wq invokes destructor for rmmod'ed helper CC: "Eric W. Biederman" <ebied...@xmission.com> Reported-by: Joe Stringer <j...@ovn.org> Signed-off-by: Florian Westphal <f...@strlen.de> --- Eric,

<    1   2   3   4   5   6   7   8   9   >