* Re: [PATCH net-next] bridge: switchdev: Use an helper to clear forward mark
From: Nikolay Aleksandrov @ 2017-09-03 15:02 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: davem, stephen, yotamg, bridge, mlxsw
In-Reply-To: <20170903144413.21946-1-idosch@mellanox.com>
On 03/09/17 17:44, Ido Schimmel wrote:
> Instead of using ifdef in the C file.
>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Suggested-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Tested-by: Yotam Gigi <yotamg@mellanox.com>
> ---
> net/bridge/br_device.c | 4 +---
> net/bridge/br_private.h | 9 +++++++++
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
Thanks for following up on this!
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads
From: Tom Herbert @ 2017-09-03 15:43 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Hannes Frederic Sowa, Saeed Mahameed, David S. Miller,
Linux Netdev List
In-Reply-To: <CALzJLG--t8VLs1GiRRVfejenB=XgpLiJHnHC+eokQ4=kwj9hGw@mail.gmail.com>
On Sat, Sep 2, 2017 at 9:11 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Sat, Sep 2, 2017 at 6:37 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Sat, Sep 2, 2017 at 6:32 PM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>>> Hi Saeed,
>>>
>>> On Sun, Sep 3, 2017, at 01:01, Saeed Mahameed wrote:
>>>> On Thu, Aug 31, 2017 at 6:51 AM, Hannes Frederic Sowa
>>>> <hannes@stressinduktion.org> wrote:
>>>> > Saeed Mahameed <saeedm@mellanox.com> writes:
>>>> >
>>>> >> The first patch from Gal and Ariel provides the mlx5 driver support for
>>>> >> ConnectX capability to perform IP version identification and matching in
>>>> >> order to distinguish between IPv4 and IPv6 without the need to specify the
>>>> >> encapsulation type, thus perform RSS in MPLS automatically without
>>>> >> specifying MPLS ethertyoe. This patch will also serve for inner GRE IPv4/6
>>>> >> classification for inner GRE RSS.
>>>> >
>>>> > I don't think this is legal at all or did I misunderstood something?
>>>> >
>>>> > <https://tools.ietf.org/html/rfc3032#section-2.2>
>>>>
>>>> It seems you misunderstood the cover letter. The HW will still
>>>> identify MPLS (IPv4/IPv6) packets using a new bit we specify in the HW
>>>> steering rules rather than adding new specific rules with {MPLS
>>>> ethertype} X {IPv4,IPv6} to classify MPLS IPv{4,6} traffic, Same
>>>> functionality a better and general way to approach it.
>>>> Bottom line the hardware is capable of processing MPLS headers and
>>>> perform RSS on the inner packet (IPv4/6) without the need of the
>>>> driver to provide precise steering MPLS rules.
>>>
>>> Sorry, I think I am still confused.
>>>
>>> I just want to make sure that you don't use the first nibble after the
>>> mpls bottom of stack label in any way as an indicator if that is an IPv4
>>> or IPv6 packet by default. It can be anything. The forward equivalence
>>> class tells the stack which protocol you see.
>>>
>>> If you match on the first nibble behind the MPLS bottom of stack label
>>> the '4' or '6' respectively could be part of a MAC address with its
>>> first nibble being 4 or 6, because the particular pseudowire is EoMPLS
>>> and uses no control world.
>>>
>>> I wanted to mention it, because with addition of e.g. VPLS this could
>>> cause problems down the road and should at least be controllable? It is
>>> probably better to use Entropy Labels in future.
>>>
>> Or just use IPv6 with flow label for RSS (or MPLS/UDP, GRE/UDP if you
>> prefer) then all this protocol specific DPI for RSS just goes away ;-)
>
> Hi Tom,
>
> How does MPLS/UDP or GRE/UDP RSS works without protocol specific DPI ?
> unlike vxlan those protocols are not over UDP and you can't just play
> with the outer header udp src port, or do you ?
>
> Can you elaborate ?
>
Hi Saeed,
An encapsulator sets the UDP source port to be the flow entropy of the
packet being encapsulated. So when the packet traverses the network
devices can base their hash just on the canonical 5-tuple which is
sufficient for ECMP and RSS. IPv6 flow label is even better since the
middleboxes don't even need to look at the transport header, a packet
is steered based on the 3-tuple of addresses and flow label. In the
Linux stack, udp_flow_src_port is used by UDP encapsulations to set
the source port. Flow label is similarly set by ip6_make_flowlabel.
Both of these functions use the skb->hash which is computed by calling
flow dissector at most once per packet (if the packet was received
with an L4 HW hash or locally originated on a connection the hash does
not need to be computed).
Please look at https://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf
as well as Davem's "Less is More" presentation which highlights the
virtues of protocol generic HW mechanisms
(https://www.youtube.com/watch?v=6VgmazGwL_Y).
Tom
^ permalink raw reply
* Re: [PATCH] Fix build on fedora-14 (and other older systems)
From: Stephen Hemminger @ 2017-09-03 15:50 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1504361702-30266-1-git-send-email-greearb@candelatech.com>
On Sat, 2 Sep 2017 07:15:02 -0700
greearb@candelatech.com wrote:
> diff --git a/include/linux/sysinfo.h b/include/linux/sysinfo.h
> index 934335a..3596b02 100644
> --- a/include/linux/sysinfo.h
> +++ b/include/linux/sysinfo.h
> @@ -3,6 +3,14 @@
>
> #include <linux/types.h>
>
> +/* So we can compile on older OSs, hopefully this is correct. --Ben */
> +#ifndef __kernel_long_t
> +typedef long __kernel_long_t;
> +#endif
> +#ifndef __kernel_ulong_t
> +typedef unsigned long __kernel_ulong_t;
> +#endif
> +
> #define SI_LOAD_SHIFT 16
> struct sysinfo {
> __kernel_long_t uptime; /* Seconds since boot */
I am not accepting this patch because all files in include/linux are automatically
regenerated from kernel 'make install_headers'. No exceptions. If you want to change
a header in include/linux it has to go through upstream kernel inclusion.
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads
From: Or Gerlitz @ 2017-09-03 16:17 UTC (permalink / raw)
To: Tom Herbert
Cc: Saeed Mahameed, Hannes Frederic Sowa, Saeed Mahameed,
David S. Miller, Linux Netdev List
In-Reply-To: <CALx6S356vRYfcsN6FaRmpn2oC0GN9-JwLsF7ybC+w4sEGGsa7w@mail.gmail.com>
On Sun, Sep 3, 2017 at 6:43 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Sat, Sep 2, 2017 at 9:11 PM, Saeed Mahameed <saeedm@dev.mellanox.co.il> wrote:
>> On Sat, Sep 2, 2017 at 6:37 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Sat, Sep 2, 2017 at 6:32 PM, Hannes Frederic Sowa
>>> <hannes@stressinduktion.org> wrote:
>>>> Hi Saeed,
>>>>
>>>> On Sun, Sep 3, 2017, at 01:01, Saeed Mahameed wrote:
>>>>> On Thu, Aug 31, 2017 at 6:51 AM, Hannes Frederic Sowa
>>>>> <hannes@stressinduktion.org> wrote:
>>>>> > Saeed Mahameed <saeedm@mellanox.com> writes:
>>>>> >
>>>>> >> The first patch from Gal and Ariel provides the mlx5 driver support for
>>>>> >> ConnectX capability to perform IP version identification and matching in
>>>>> >> order to distinguish between IPv4 and IPv6 without the need to specify the
>>>>> >> encapsulation type, thus perform RSS in MPLS automatically without
>>>>> >> specifying MPLS ethertyoe. This patch will also serve for inner GRE IPv4/6
>>>>> >> classification for inner GRE RSS.
>>>>> >
>>>>> > I don't think this is legal at all or did I misunderstood something?
>>>>> >
>>>>> > <https://tools.ietf.org/html/rfc3032#section-2.2>
>>>>>
>>>>> It seems you misunderstood the cover letter. The HW will still
>>>>> identify MPLS (IPv4/IPv6) packets using a new bit we specify in the HW
>>>>> steering rules rather than adding new specific rules with {MPLS
>>>>> ethertype} X {IPv4,IPv6} to classify MPLS IPv{4,6} traffic, Same
>>>>> functionality a better and general way to approach it.
>>>>> Bottom line the hardware is capable of processing MPLS headers and
>>>>> perform RSS on the inner packet (IPv4/6) without the need of the
>>>>> driver to provide precise steering MPLS rules.
>>>>
>>>> Sorry, I think I am still confused.
>>>>
>>>> I just want to make sure that you don't use the first nibble after the
>>>> mpls bottom of stack label in any way as an indicator if that is an IPv4
>>>> or IPv6 packet by default. It can be anything. The forward equivalence
>>>> class tells the stack which protocol you see.
>>>>
>>>> If you match on the first nibble behind the MPLS bottom of stack label
>>>> the '4' or '6' respectively could be part of a MAC address with its
>>>> first nibble being 4 or 6, because the particular pseudowire is EoMPLS
>>>> and uses no control world.
>>>>
>>>> I wanted to mention it, because with addition of e.g. VPLS this could
>>>> cause problems down the road and should at least be controllable? It is
>>>> probably better to use Entropy Labels in future.
>>>>
>>> Or just use IPv6 with flow label for RSS (or MPLS/UDP, GRE/UDP if you
>>> prefer) then all this protocol specific DPI for RSS just goes away ;-)
>> How does MPLS/UDP or GRE/UDP RSS works without protocol specific DPI ?
>> unlike vxlan those protocols are not over UDP and you can't just play
>> with the outer header udp src port, or do you ?
>> Can you elaborate ?
> An encapsulator sets the UDP source port to be the flow entropy of the
> packet being encapsulated. So when the packet traverses the network
> devices can base their hash just on the canonical 5-tuple which is
> sufficient for ECMP and RSS. IPv6 flow label is even better since the
> middleboxes don't even need to look at the transport header, a packet
> is steered based on the 3-tuple of addresses and flow label. In the
> Linux stack, udp_flow_src_port is used by UDP encapsulations to set
> the source port. Flow label is similarly set by ip6_make_flowlabel.
> Both of these functions use the skb->hash which is computed by calling
> flow dissector at most once per packet (if the packet was received
> with an L4 HW hash or locally originated on a connection the hash does
> not need to be computed).
Hi Tom,
Re all sorts of udp encap, sure, we're all on the less-is-more thing and just
RSS-ing on the ip+udp encap header.
For GRE, I was trying to fight back that rss-ing on inner, but as
Saeed commented,
we didn't see something simple through which the HW can do spreading. To make
sure I follow, you are saying that if this is gre6 tunneling
net-next.git]# git grep -p ip6_make_flowlabel net/ include/linux/ include/net/
include/net/ipv6.h=static inline void iph_to_flow_copy_v6addrs(struct
flow_keys *flow,
include/net/ipv6.h:static inline __be32 ip6_make_flowlabel(struct net
*net, struct sk_buff *skb,
include/net/ipv6.h=static inline void ip6_set_txhash(struct sock *sk) { }
include/net/ipv6.h:static inline __be32 ip6_make_flowlabel(struct net
*net, struct sk_buff *skb,
net/ipv6/ip6_gre.c=static int ip6gre_header(struct sk_buff *skb,
struct net_device *dev,
net/ipv6/ip6_gre.c: ip6_make_flowlabel(dev_net(dev), skb,
net/ipv6/ip6_output.c=int ip6_xmit(const struct sock *sk, struct
sk_buff *skb, struct flowi6 *fl6,
net/ipv6/ip6_output.c: ip6_flow_hdr(hdr, tclass,
ip6_make_flowlabel(net, skb, fl6->flowlabel,
net/ipv6/ip6_output.c=struct sk_buff *__ip6_make_skb(struct sock *sk,
net/ipv6/ip6_output.c: ip6_make_flowlabel(net, skb,
fl6->flowlabel,
net/ipv6/ip6_tunnel.c=int ip6_tnl_xmit(struct sk_buff *skb, struct
net_device *dev, __u8 dsfield,
net/ipv6/ip6_tunnel.c: ip6_make_flowlabel(net, skb,
fl6->flowlabel, true, fl6));
the sender side (ip6_tnl_xmit?) will set the IPv6 flow label in a
similar manner done by udp_flow_src_port? and
if the receiver side hashes on L3 IPv6 src/dst/flow label we'll get
spreading? nice!
Still, what do we do with IPv4 GRE tunnels? and what do we do with HW
which isn't capable to RSS on flow label?
> Please look at https://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf
> as well as Davem's "Less is More" presentation which highlights the
> virtues of protocol generic HW mechanisms
> (https://www.youtube.com/watch?v=6VgmazGwL_Y).
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads
From: Tom Herbert @ 2017-09-03 16:45 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Hannes Frederic Sowa, Saeed Mahameed,
David S. Miller, Linux Netdev List
In-Reply-To: <CAJ3xEMiNKVZnPcqDavmRduQjJRZSOZTFYOP1-ghpREXegLaB-A@mail.gmail.com>
> Re all sorts of udp encap, sure, we're all on the less-is-more thing and just
> RSS-ing on the ip+udp encap header.
>
> For GRE, I was trying to fight back that rss-ing on inner, but as
> Saeed commented,
> we didn't see something simple through which the HW can do spreading. To make
> sure I follow, you are saying that if this is gre6 tunneling
>
It's pretty common that HW does this since GRE is in widespread use for a while.
> net-next.git]# git grep -p ip6_make_flowlabel net/ include/linux/ include/net/
> include/net/ipv6.h=static inline void iph_to_flow_copy_v6addrs(struct
> flow_keys *flow,
> include/net/ipv6.h:static inline __be32 ip6_make_flowlabel(struct net
> *net, struct sk_buff *skb,
> include/net/ipv6.h=static inline void ip6_set_txhash(struct sock *sk) { }
> include/net/ipv6.h:static inline __be32 ip6_make_flowlabel(struct net
> *net, struct sk_buff *skb,
> net/ipv6/ip6_gre.c=static int ip6gre_header(struct sk_buff *skb,
> struct net_device *dev,
> net/ipv6/ip6_gre.c: ip6_make_flowlabel(dev_net(dev), skb,
> net/ipv6/ip6_output.c=int ip6_xmit(const struct sock *sk, struct
> sk_buff *skb, struct flowi6 *fl6,
> net/ipv6/ip6_output.c: ip6_flow_hdr(hdr, tclass,
> ip6_make_flowlabel(net, skb, fl6->flowlabel,
> net/ipv6/ip6_output.c=struct sk_buff *__ip6_make_skb(struct sock *sk,
> net/ipv6/ip6_output.c: ip6_make_flowlabel(net, skb,
> fl6->flowlabel,
> net/ipv6/ip6_tunnel.c=int ip6_tnl_xmit(struct sk_buff *skb, struct
> net_device *dev, __u8 dsfield,
> net/ipv6/ip6_tunnel.c: ip6_make_flowlabel(net, skb,
> fl6->flowlabel, true, fl6));
>
Seems right.
> the sender side (ip6_tnl_xmit?) will set the IPv6 flow label in a
> similar manner done by udp_flow_src_port? and
> if the receiver side hashes on L3 IPv6 src/dst/flow label we'll get
> spreading? nice!
>
As long as the network devices support it.
> Still, what do we do with IPv4 GRE tunnels? and what do we do with HW
> which isn't capable to RSS on flow label?
>
Throw it out and buy hardware that supports flow label! ;-)
Seriously though, flow labels are the only reasonable way that RSS can
be supported in IPv6. If a device tries to do DPI on IPv6 then they'll
eventually need to be able to parse of some number of extension
headers which unlike IPv4 is unbounded in size. So there are going to
be circumstances in which a device either doesn't understand an EH, or
the size of EHs blows it parsing buffer limit so it can't do the DPI.
IMO, telling host implementations that we're not allowed to use
extension headers because middleboxes can't support them is
unacceptable...
Btw, these same arguments apply as to why CHECKSUM_COMPLETE is the
only reasonable way to handle receive checksums in IPv6.
Tom
^ permalink raw reply
* Re: [PATCH net] ipv4: Don't override return code from ip_route_input_noref()
From: David Miller @ 2017-09-03 17:55 UTC (permalink / raw)
To: sd; +Cc: sbrivio, netdev, weiwan
In-Reply-To: <20170831234506.GA1838@bistromath.localdomain>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Fri, 1 Sep 2017 01:45:06 +0200
> 2017-08-31, 18:11:41 +0200, Stefano Brivio wrote:
>> After ip_route_input() calls ip_route_input_noref(), another
>> check on skb_dst() is done, but if this fails, we shouldn't
>> override the return code from ip_route_input_noref(), as it
>> could have been more specific (i.e. -EHOSTUNREACH).
>>
>> This also saves one call to skb_dst_force_safe() and one to
>> skb_dst() in case the ip_route_input_noref() check fails.
>>
>> Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
>> Fixes: ad65a2f05695 ("ipv4: call dst_hold_safe() properly")
>
> That should be instead:
>
> Fixes: 9df16efadd2a ("ipv4: call dst_hold_safe() properly")
>
> Acked-by: Sabrina Dubroca <sd@queasysnail.net>
Applied with fixed Fixes: tag, thanks.
^ permalink raw reply
* Re: [PATCH][next] net/mlx4_core: fix memory leaks on error exit path
From: David Miller @ 2017-09-03 17:57 UTC (permalink / raw)
To: colin.king; +Cc: tariqt, netdev, linux-rdma, kernel-janitors, linux-kernel
In-Reply-To: <20170831163053.2349-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 31 Aug 2017 17:30:53 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The structures hca_param and func_cap are not being kfree'd on an error
> exit path causing two memory leaks. Fix this by jumping to the existing
> free memory error exit path.
>
> Detected by CoverityScan, CID#1455219, CID#1455224 ("Resource Leak")
>
> Fixes: c73c8b1e47ca ("net/mlx4_core: Dynamically allocate structs at mlx4_slave_cap")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH][next] net/mlx4_core: fix incorrect size allocation for dev->caps.spec_qps
From: David Miller @ 2017-09-03 17:57 UTC (permalink / raw)
To: colin.king-Z7WLFzj8eWMS+FvcfC7Uqw
Cc: tariqt-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170831170724.3747-1-colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
From: Colin King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Date: Thu, 31 Aug 2017 18:07:24 +0100
> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
>
> The current allocation for dev->caps.spec_qps is for the size of the
> pointer and not the size of the actual mlx4_spec_qps structure. Fix
> this by using the correct size. Also splint allocation over a few
> lines to make it cppcheck clean on overly wide lines.
>
> Detected by CoverityScan, CID#1455222 ("Wrong sizeof argument")
>
> Fixes: c73c8b1e47ca ("net/mlx4_core: Dynamically allocate structs at mlx4_slave_cap")
> Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 0/2] net: revert lib/percpu_counter API for fragmentation mem accounting
From: David Miller @ 2017-09-03 18:01 UTC (permalink / raw)
To: brouer; +Cc: netdev, mkubecek, fw, liujian56
In-Reply-To: <150425790711.22227.12264977619066874632.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Fri, 01 Sep 2017 11:26:03 +0200
> There is a bug in fragmentation codes use of the percpu_counter API,
> that can cause issues on systems with many CPUs, above 24 CPUs.
>
> After much consideration and different attempts at solving the API
> usage. The conclusion is to revert to the simple atomic_t API instead.
>
> The ratio between batch size and threshold size make it a bad use-case
> for the lib/percpu_counter API. As using the correct API calls will
> unfortunately cause systems with many CPUs to always execute an
> expensive sum across all CPUs. Plus the added complexity is not worth it.
Series applied, thanks Jesper.
^ permalink raw reply
* Re: [PATCH net 0/2] l2tp: session creation fixes
From: David Miller @ 2017-09-03 18:04 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman
In-Reply-To: <cover.1504277892.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Fri, 1 Sep 2017 17:58:45 +0200
> The session creation process has a few issues wrt. concurrent tunnel
> deletion.
>
> Patch #1 avoids creating sessions in tunnels that are getting removed.
> This prevents races where sessions could try to take tunnel resources
> that were already released.
>
> Patch #2 removes some racy l2tp_tunnel_find() calls in session creation
> callbacks. Together with path #1 it ensures that sessions can only
> access tunnel resources that are guaranteed to remain valid during the
> session creation process.
>
>
> There are other problems with how sessions are created: pseudo-wire
> specific data are set after the session is added to the tunnel. So
> the session can be used, or deleted, before it has been completely
> initialised. Separating session allocation from session registration
> would be necessary, but we'd still have circular dependencies
> preventing race-free registration. I'll consider this issue in future
> series.
Series applied, thanks.
^ permalink raw reply
* [PATCH RFC v3 0/4] Add cross-compilation support to eBPF samples
From: Joel Fernandes @ 2017-09-03 18:23 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: kernel-team, Juri Lelli, Alison Chaiken, Chenbo Feng,
Joel Fernandes, Alexei Starovoitov, Daniel Borkmann, David Miller
These patches fix issues seen when cross-compiling eBPF samples on arm64.
Compared to [1], I dropped the controversial inline-asm patch pending further
discussion on the right way to do it. However these patches are still a step in
the right direction and I wanted them to get in before the more controversial
bit.
[1] https://lkml.org/lkml/2017/8/7/417
Joel Fernandes (4):
samples/bpf: Use getppid instead of getpgrp for array map stress
samples/bpf: Enable cross compiler support
samples/bpf: Fix pt_regs issues when cross-compiling
samples/bpf: Add documentation on cross compilation
samples/bpf/Makefile | 7 +++-
samples/bpf/README.rst | 10 ++++++
samples/bpf/map_perf_test_kern.c | 2 +-
samples/bpf/map_perf_test_user.c | 2 +-
tools/testing/selftests/bpf/bpf_helpers.h | 56 +++++++++++++++++++++++++++----
5 files changed, 67 insertions(+), 10 deletions(-)
CC: Alexei Starovoitov <ast@kernel.org>
CC: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Miller <davem@davemloft.net>
--
2.14.1.581.gf28d330327-goog
^ permalink raw reply
* [PATCH RFC v3 1/4] samples/bpf: Use getppid instead of getpgrp for array map stress
From: Joel Fernandes @ 2017-09-03 18:25 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: kernel-team, Juri Lelli, Alison Chaiken, Chenbo Feng,
Joel Fernandes, Alexei Starovoitov, Daniel Borkmann, David Miller
When cross-compiling the bpf sample map_perf_test for aarch64, I find that
__NR_getpgrp is undefined. This causes build errors. This syscall is deprecated
and requires defining __ARCH_WANT_SYSCALL_DEPRECATED. To avoid having to define
that, just use a different syscall (getppid) for the array map stress test.
CC: Alexei Starovoitov <ast@kernel.org>
CC: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Joel Fernandes <joelaf@google.com>
---
samples/bpf/map_perf_test_kern.c | 2 +-
samples/bpf/map_perf_test_user.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/samples/bpf/map_perf_test_kern.c b/samples/bpf/map_perf_test_kern.c
index 098c857f1eda..2b2ffb97018b 100644
--- a/samples/bpf/map_perf_test_kern.c
+++ b/samples/bpf/map_perf_test_kern.c
@@ -266,7 +266,7 @@ int stress_hash_map_lookup(struct pt_regs *ctx)
return 0;
}
-SEC("kprobe/sys_getpgrp")
+SEC("kprobe/sys_getppid")
int stress_array_map_lookup(struct pt_regs *ctx)
{
u32 key = 1, i;
diff --git a/samples/bpf/map_perf_test_user.c b/samples/bpf/map_perf_test_user.c
index f388254896f6..a0310fc70057 100644
--- a/samples/bpf/map_perf_test_user.c
+++ b/samples/bpf/map_perf_test_user.c
@@ -282,7 +282,7 @@ static void test_array_lookup(int cpu)
start_time = time_get_ns();
for (i = 0; i < max_cnt; i++)
- syscall(__NR_getpgrp, 0);
+ syscall(__NR_getppid, 0);
printf("%d:array_lookup %lld lookups per sec\n",
cpu, max_cnt * 1000000000ll * 64 / (time_get_ns() - start_time));
}
--
2.14.1.581.gf28d330327-goog
^ permalink raw reply related
* [PATCH RFC v3 2/4] samples/bpf: Enable cross compiler support
From: Joel Fernandes @ 2017-09-03 18:25 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: kernel-team, Juri Lelli, Alison Chaiken, Chenbo Feng,
Joel Fernandes, Alexei Starovoitov, Daniel Borkmann, David Miller
In-Reply-To: <20170903182549.30866-1-joelaf@google.com>
When cross compiling, bpf samples use HOSTCC for compiling the non-BPF part of
the sample, however what we really want is to use the cross compiler to build
for the cross target since that is what will load and run the BPF sample.
Detect this and compile samples correctly.
CC: Alexei Starovoitov <ast@kernel.org>
CC: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Joel Fernandes <joelaf@google.com>
---
samples/bpf/Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index cf17c7932a6e..13f74b67ca44 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -177,6 +177,11 @@ HOSTLOADLIBES_syscall_tp += -lelf
LLC ?= llc
CLANG ?= clang
+# Detect that we're cross compiling and use the cross compiler
+ifdef CROSS_COMPILE
+HOSTCC = $(CROSS_COMPILE)gcc
+endif
+
# Trick to allow make to be run from this directory
all:
$(MAKE) -C ../../ $(CURDIR)/
--
2.14.1.581.gf28d330327-goog
^ permalink raw reply related
* [PATCH RFC v3 3/4] samples/bpf: Fix pt_regs issues when cross-compiling
From: Joel Fernandes @ 2017-09-03 18:25 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: kernel-team, Juri Lelli, Alison Chaiken, Chenbo Feng,
Joel Fernandes, Alexei Starovoitov, Daniel Borkmann, David Miller
In-Reply-To: <20170903182549.30866-1-joelaf@google.com>
BPF samples fail to build when cross-compiling for ARM64 because of incorrect
pt_regs param selection. This is because clang defines __x86_64__ and
bpf_headers thinks we're building for x86. Since clang is building for the BPF
target, it shouldn't make assumptions about what target the BPF program is
going to run on. To fix this, lets pass ARCH so the header knows which target
the BPF program is being compiled for and can use the correct pt_regs code.
CC: Alexei Starovoitov <ast@kernel.org>
CC: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Joel Fernandes <joelaf@google.com>
---
samples/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/bpf_helpers.h | 56 +++++++++++++++++++++++++++----
2 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 13f74b67ca44..ebc2ad69b62c 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -230,7 +230,7 @@ $(obj)/%.o: $(src)/%.c
$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
-I$(srctree)/tools/testing/selftests/bpf/ \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
- -Wno-compare-distinct-pointer-types \
+ -D__TARGET_ARCH_$(ARCH) -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
index 36fb9161b34a..4875395b0b52 100644
--- a/tools/testing/selftests/bpf/bpf_helpers.h
+++ b/tools/testing/selftests/bpf/bpf_helpers.h
@@ -109,7 +109,47 @@ static int (*bpf_skb_under_cgroup)(void *ctx, void *map, int index) =
static int (*bpf_skb_change_head)(void *, int len, int flags) =
(void *) BPF_FUNC_skb_change_head;
+/* Scan the ARCH passed in from ARCH env variable (see Makefile) */
+#if defined(__TARGET_ARCH_x86)
+ #define bpf_target_x86
+ #define bpf_target_defined
+#elif defined(__TARGET_ARCH_s930x)
+ #define bpf_target_s930x
+ #define bpf_target_defined
+#elif defined(__TARGET_ARCH_arm64)
+ #define bpf_target_arm64
+ #define bpf_target_defined
+#elif defined(__TARGET_ARCH_mips)
+ #define bpf_target_mips
+ #define bpf_target_defined
+#elif defined(__TARGET_ARCH_powerpc)
+ #define bpf_target_powerpc
+ #define bpf_target_defined
+#elif defined(__TARGET_ARCH_sparc)
+ #define bpf_target_sparc
+ #define bpf_target_defined
+#else
+ #undef bpf_target_defined
+#endif
+
+/* Fall back to what the compiler says */
+#ifndef bpf_target_defined
#if defined(__x86_64__)
+ #define bpf_target_x86
+#elif defined(__s390x__)
+ #define bpf_target_s930x
+#elif defined(__aarch64__)
+ #define bpf_target_arm64
+#elif defined(__mips__)
+ #define bpf_target_mips
+#elif defined(__powerpc__)
+ #define bpf_target_powerpc
+#elif defined(__sparc__)
+ #define bpf_target_sparc
+#endif
+#endif
+
+#if defined(bpf_target_x86)
#define PT_REGS_PARM1(x) ((x)->di)
#define PT_REGS_PARM2(x) ((x)->si)
@@ -122,7 +162,7 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
#define PT_REGS_SP(x) ((x)->sp)
#define PT_REGS_IP(x) ((x)->ip)
-#elif defined(__s390x__)
+#elif defined(bpf_target_s390x)
#define PT_REGS_PARM1(x) ((x)->gprs[2])
#define PT_REGS_PARM2(x) ((x)->gprs[3])
@@ -135,7 +175,7 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
#define PT_REGS_SP(x) ((x)->gprs[15])
#define PT_REGS_IP(x) ((x)->psw.addr)
-#elif defined(__aarch64__)
+#elif defined(bpf_target_arm64)
#define PT_REGS_PARM1(x) ((x)->regs[0])
#define PT_REGS_PARM2(x) ((x)->regs[1])
@@ -148,7 +188,7 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
#define PT_REGS_SP(x) ((x)->sp)
#define PT_REGS_IP(x) ((x)->pc)
-#elif defined(__mips__)
+#elif defined(bpf_target_mips)
#define PT_REGS_PARM1(x) ((x)->regs[4])
#define PT_REGS_PARM2(x) ((x)->regs[5])
@@ -161,7 +201,7 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
#define PT_REGS_SP(x) ((x)->regs[29])
#define PT_REGS_IP(x) ((x)->cp0_epc)
-#elif defined(__powerpc__)
+#elif defined(bpf_target_powerpc)
#define PT_REGS_PARM1(x) ((x)->gpr[3])
#define PT_REGS_PARM2(x) ((x)->gpr[4])
@@ -172,7 +212,7 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
#define PT_REGS_SP(x) ((x)->sp)
#define PT_REGS_IP(x) ((x)->nip)
-#elif defined(__sparc__)
+#elif defined(bpf_target_sparc)
#define PT_REGS_PARM1(x) ((x)->u_regs[UREG_I0])
#define PT_REGS_PARM2(x) ((x)->u_regs[UREG_I1])
@@ -182,6 +222,8 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
#define PT_REGS_RET(x) ((x)->u_regs[UREG_I7])
#define PT_REGS_RC(x) ((x)->u_regs[UREG_I0])
#define PT_REGS_SP(x) ((x)->u_regs[UREG_FP])
+
+/* Should this also be a bpf_target check for the sparc case? */
#if defined(__arch64__)
#define PT_REGS_IP(x) ((x)->tpc)
#else
@@ -190,10 +232,10 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
#endif
-#ifdef __powerpc__
+#ifdef bpf_target_powerpc
#define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ (ip) = (ctx)->link; })
#define BPF_KRETPROBE_READ_RET_IP BPF_KPROBE_READ_RET_IP
-#elif defined(__sparc__)
+#elif bpf_target_sparc
#define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ (ip) = PT_REGS_RET(ctx); })
#define BPF_KRETPROBE_READ_RET_IP BPF_KPROBE_READ_RET_IP
#else
--
2.14.1.581.gf28d330327-goog
^ permalink raw reply related
* [PATCH RFC v3 4/4] samples/bpf: Add documentation on cross compilation
From: Joel Fernandes @ 2017-09-03 18:25 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: kernel-team, Juri Lelli, Alison Chaiken, Chenbo Feng,
Joel Fernandes, Alexei Starovoitov, Daniel Borkmann, David Miller
In-Reply-To: <20170903182549.30866-1-joelaf@google.com>
CC: Alexei Starovoitov <ast@kernel.org>
CC: Daniel Borkmann <daniel@iogearbox.net>
CC: David Miller <davem@davemloft.net>
Signed-off-by: Joel Fernandes <joelaf@google.com>
---
samples/bpf/README.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
index 79f9a58f1872..2b906127ef54 100644
--- a/samples/bpf/README.rst
+++ b/samples/bpf/README.rst
@@ -64,3 +64,13 @@ It is also possible to point make to the newly compiled 'llc' or
'clang' command via redefining LLC or CLANG on the make command line::
make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
+
+Cross compiling samples
+-----------------------
+Inorder to cross-compile, say for arm64 targets, export CROSS_COMPILE and ARCH
+environment variables before calling make. This will direct make to build
+samples for the cross target.
+
+export ARCH=arm64
+export CROSS_COMPILE="aarch64-linux-gnu-"
+make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
--
2.14.1.581.gf28d330327-goog
^ permalink raw reply related
* Re: [PATCH] Fix build on fedora-14 (and other older systems)
From: Ben Greear @ 2017-09-03 18:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170903085004.5b5ded4f@xeon-e3>
On 09/03/2017 08:50 AM, Stephen Hemminger wrote:
> On Sat, 2 Sep 2017 07:15:02 -0700
> greearb@candelatech.com wrote:
>
>> diff --git a/include/linux/sysinfo.h b/include/linux/sysinfo.h
>> index 934335a..3596b02 100644
>> --- a/include/linux/sysinfo.h
>> +++ b/include/linux/sysinfo.h
>> @@ -3,6 +3,14 @@
>>
>> #include <linux/types.h>
>>
>> +/* So we can compile on older OSs, hopefully this is correct. --Ben */
>> +#ifndef __kernel_long_t
>> +typedef long __kernel_long_t;
>> +#endif
>> +#ifndef __kernel_ulong_t
>> +typedef unsigned long __kernel_ulong_t;
>> +#endif
>> +
>> #define SI_LOAD_SHIFT 16
>> struct sysinfo {
>> __kernel_long_t uptime; /* Seconds since boot */
>
> I am not accepting this patch because all files in include/linux are automatically
> regenerated from kernel 'make install_headers'. No exceptions. If you want to change
> a header in include/linux it has to go through upstream kernel inclusion.
It would be wrong to add this to the actual kernel header I think.
Do you have another suggestion for fixing iproute2 compile?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads
From: Or Gerlitz @ 2017-09-03 18:58 UTC (permalink / raw)
To: Tom Herbert
Cc: Saeed Mahameed, Hannes Frederic Sowa, Saeed Mahameed,
David S. Miller, Linux Netdev List
In-Reply-To: <CALx6S34c_Kw9MXxM9hxtps0pOQYScJHftzdJ_pun68xjQzcGHA@mail.gmail.com>
On Sun, Sep 3, 2017 at 7:45 PM, Tom Herbert <tom@herbertland.com> wrote:
>> Re all sorts of udp encap, sure, we're all on the less-is-more thing and just
>> RSS-ing on the ip+udp encap header.
>> For GRE, I was trying to fight back that rss-ing on inner, but as
>> Saeed commented,
>> we didn't see something simple through which the HW can do spreading. To
>> make sure I follow, you are saying that if this is gre6 tunneling
> It's pretty common that HW does this since GRE is in widespread use for a while.
ECMP? I guess so
>> the sender side (ip6_tnl_xmit?) will set the IPv6 flow label in a
>> similar manner done by udp_flow_src_port? and
>> if the receiver side hashes on L3 IPv6 src/dst/flow label we'll get
>> spreading? nice!
> As long as the network devices support it.
yeah, hopefully upcoming devices will support the thing
>> Still, what do we do with IPv4 GRE tunnels? and what do we do with HW
>> which isn't capable to RSS on flow label?
> Throw it out and buy hardware that supports flow label! ;-)
still, we came across IPv4 GRE customer environments
> Seriously though, flow labels are the only reasonable way that RSS can
> be supported in IPv6. If a device tries to do DPI on IPv6 then they'll
> eventually need to be able to parse of some number of extension
> headers which unlike IPv4 is unbounded in size. So there are going to
> be circumstances in which a device either doesn't understand an EH, or
> the size of EHs blows it parsing buffer limit so it can't do the DPI.
> IMO, telling host implementations that we're not allowed to use
> extension headers because middleboxes can't support them is
> unacceptable...
makes sense to me
> Btw, these same arguments apply as to why CHECKSUM_COMPLETE is the
> only reasonable way to handle receive checksums in IPv6.
supported on mlx5
^ permalink raw reply
* [PATCH][next] rocker: fix kcalloc parameter order
From: Zahari Doychev @ 2017-09-03 20:26 UTC (permalink / raw)
To: jiri, netdev; +Cc: Zahari Doychev
The function calls to kcalloc use wrong parameter order. The flags
have to be passed as last parameter.
The change was done using the following coccinelle script:
@@
expression E1,E2;
type T;
@@
-kcalloc(E1, E2, sizeof(T))
+kcalloc(E2, sizeof(T), E1)
Signed-off-by: Zahari Doychev <zahari.doychev@linux.com>
---
drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
index da4e26b53a52..2708451ce22a 100644
--- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
+++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
@@ -1177,7 +1177,7 @@ static int ofdpa_group_l2_fan_out(struct ofdpa_port *ofdpa_port,
entry->group_id = group_id;
entry->group_count = group_count;
- entry->group_ids = kcalloc(flags, group_count, sizeof(u32));
+ entry->group_ids = kcalloc(group_count, sizeof(u32), flags);
if (!entry->group_ids) {
kfree(entry);
return -ENOMEM;
@@ -1456,7 +1456,7 @@ static int ofdpa_port_vlan_flood_group(struct ofdpa_port *ofdpa_port,
int err = 0;
int i;
- group_ids = kcalloc(flags, port_count, sizeof(u32));
+ group_ids = kcalloc(port_count, sizeof(u32), flags);
if (!group_ids)
return -ENOMEM;
--
2.13.0
^ permalink raw reply related
* Re: [PATCH v3 2/3] dt-binding: net: sfp binding documentation
From: Russell King - ARM Linux @ 2017-09-03 20:46 UTC (permalink / raw)
To: Baruch Siach
Cc: Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S. Miller, netdev, devicetree, Sergei Shtylyov
In-Reply-To: <01ae7bc45d68322669d18a4feeaeef733ba888d7.1504441874.git.baruch@tkos.co.il>
On Sun, Sep 03, 2017 at 03:31:13PM +0300, Baruch Siach wrote:
> Add device-tree binding documentation SFP transceivers. Support for SFP
> transceivers has been recently introduced (drivers/net/phy/sfp.c).
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> v3:
> Mention gpios phandle and specifier
> Mention the polarity of each gpio
> Fix example property names
>
> v2:
> Rename -gpio properties to -gpios
> Rename the rate-select-gpio property to rate-select0-gpios
> Add the rate-select1-gpios property
> Add examples
> ---
> Documentation/devicetree/bindings/net/sff,sfp.txt | 78 +++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/sff,sfp.txt
>
> diff --git a/Documentation/devicetree/bindings/net/sff,sfp.txt b/Documentation/devicetree/bindings/net/sff,sfp.txt
> new file mode 100644
> index 000000000000..b98ee5945265
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/sff,sfp.txt
> @@ -0,0 +1,78 @@
> +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
> +Transceiver
> +
> +Required properties:
> +
> +- compatible : must be "sff,sfp"
> +
> +Optional Properties:
> +
> +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> + interface
> +
> +- moddef0-gpios : GPIO phandle and a single specifier of the MOD-DEF0 (AKA
> + Mod_ABS) module presence input gpio signal, active (module absent) high
> +
> +- los-gpios : GPIO phandle and a single specifier of the Receiver Loss of
> + Signal Indication input gpio signal, active (signal lost) high
> +
> +- tx-fault-gpios : GPIO phandle and a single specifier of the Module
> + Transmitter Fault input gpio signal, active (fault condition) high
> +
> +- tx-disable-gpios : GPIO phandle and a single specifier of the Transmitter
> + Disable output gpio signal, active (Tx disable) high
> +
> +- rate-select0-gpios : GPIO phandle and a single specifier of the Rx Signaling
> + Rate Select (AKA RS0) output gpio signal, low: low Rx rate, high: high Rx
> + rate
> +
> +- rate-select1-gpios : GPIO phandle and a single specifier of the Tx Signaling
> + Rate Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate,
> + high: high Tx rate
> +
> +Example #1: Direct serdes to SFP connection
> +
> +sfp_eth3: sfp-eth3 {
> + compatible = "sff,sfp";
> + i2c-bus = <&sfp_1g_i2c>;
> + los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>;
> + moddef0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>;
> + tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>;
> + tx-fault-gpios = <&cpm_gpio2 19 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&cps_emac3 {
> + phy-mode = "sgmii";
> + phy-names = "comphy";
> + phys = <&cps_comphy 5 COMPHY_SGMII2>;
I don't like this level of example - SGMII is Cisco SGMII which is not
the same as 1000Base-X - the two are incompatible. Fibre SFP modules
only work with 1000Base-X.
The SFP/phylink takes care of informing the MAC which mode it should
be in, and the MAC must configure itself appropriately in response to
that, otherwise the module can't be supported.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup
From: Bjorn Andersson @ 2017-09-03 21:10 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Rob Herring, Gustavo F. Padovan, Johan Hedberg, David S. Miller,
open list:BLUETOOTH DRIVERS, Network Development, LKML,
linux-arm-msm, Loic Poulain
In-Reply-To: <CD710538-22CB-45E5-B54E-ACB97E84D42E@holtmann.org>
On Fri 01 Sep 23:12 PDT 2017, Marcel Holtmann wrote:
> Hi Rob,
>
> >>> Bluetooth BD address can be retrieved in the same way as
> >>> for wcnss-wlan MAC address. This patch mainly stores the
> >>> local-mac-address property and sets the BD address during
> >>> hci device setup.
> >>>
> >>> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> >>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >>> ---
> >>> drivers/bluetooth/btqcomsmd.c | 28 ++++++++++++++++++++++++++++
> >>> 1 file changed, 28 insertions(+)
> >>>
> >>> diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
> >>> index d00c4fdae924..443bb2099329 100644
> >>> --- a/drivers/bluetooth/btqcomsmd.c
> >>> +++ b/drivers/bluetooth/btqcomsmd.c
> >>> @@ -26,6 +26,7 @@
> >>> struct btqcomsmd {
> >>> struct hci_dev *hdev;
> >>>
> >>> + const bdaddr_t *addr;
> >>> struct rpmsg_endpoint *acl_channel;
> >>> struct rpmsg_endpoint *cmd_channel;
> >>> };
> >>> @@ -100,6 +101,27 @@ static int btqcomsmd_close(struct hci_dev *hdev)
> >>> return 0;
> >>> }
> >>>
> >>> +static int btqcomsmd_setup(struct hci_dev *hdev)
> >>> +{
> >>> + struct btqcomsmd *btq = hci_get_drvdata(hdev);
> >>> + struct sk_buff *skb;
> >>> +
> >>> + skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
> >>> + if (IS_ERR(skb))
> >>> + return PTR_ERR(skb);
> >>> + kfree_skb(skb);
> >>> +
> >>> + if (btq->addr) {
> >>> + bdaddr_t bdaddr;
> >>> +
> >>> + /* btq->addr stored with most significant byte first */
> >>> + baswap(&bdaddr, btq->addr);
> >>> + return qca_set_bdaddr_rome(hdev, &bdaddr);
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> static int btqcomsmd_probe(struct platform_device *pdev)
> >>> {
> >>> struct btqcomsmd *btq;
> >>> @@ -123,6 +145,11 @@ static int btqcomsmd_probe(struct platform_device *pdev)
> >>> if (IS_ERR(btq->cmd_channel))
> >>> return PTR_ERR(btq->cmd_channel);
> >>>
> >>> + btq->addr = of_get_property(pdev->dev.of_node, "local-mac-address",
> >>> + &ret);
> >>> + if (ret != sizeof(bdaddr_t))
> >>> + btq->addr = NULL;
> >>> +
> >>> hdev = hci_alloc_dev();
> >>> if (!hdev)
> >>> return -ENOMEM;
> >>> @@ -135,6 +162,7 @@ static int btqcomsmd_probe(struct platform_device *pdev)
> >>> hdev->open = btqcomsmd_open;
> >>> hdev->close = btqcomsmd_close;
> >>> hdev->send = btqcomsmd_send;
> >>> + hdev->setup = btqcomsmd_setup;
> >>> hdev->set_bdaddr = qca_set_bdaddr_rome;
> >>
> >> I do not like this patch. Why not just set HCI_QUIRK_INVALID_BDADDR and let a userspace tool deal with reading the BD_ADDR from some storage.
> >>
> >> Frankly I do not get this WiFI MAC address or BD_ADDR stored in DT. I assumed the DT is suppose to describe hardware and not some value that is normally retrieved for OTP or alike.
> >
> > Use of "local-mac-address" for ethernet at least has existed as long
> > at OpenFirmware I think. For some platforms, DT is the only OTP. And
> > sometimes, the bootloader (like u-boot) stores MAC addresses and then
> > populates them on boot.
> >
> > Seems like if we just let userspace deal with it, then we're back to a
> > btattach tool with every platform's specific way of reading the MAC
> > address.
>
> for Bluetooth that is not true. We have Set Public Address command
> that is uniquely handling this and the HCI_QUIRK_INVALID_BDADDR
> address does the right magic to allow userspace to identify a missing
> address. It is done nicely and correctly and works fine.
>
You're right in that we have a nice standardized way of informing user
space that the bd address is invalid and a nice standardized way for the
user to specify an address.
What I believe Rob is saying (and what is my problem) is that the user
space tool reading the address from somewhere and calling this API is
not standard - so we end up maintaining some custom
"read-address-and-call-public-address"-tool for both Debian and
OpenEmbedded, plus we need to ensure that all our customers include and
launch this tool in their own systems.
> Mind you this is even used when there actually is a BD_ADDR, but the
> device manufacturer wants to have one from its own OUI range compared
> to the chip manufacturer’s OUI range.
>
> If DT is really the only place for the BD_ADDR and the bootloader
> kinda does add / merge it into the DT, then by all means that is fine.
> However if it is not, then this feature is dangerous since it can lead
> to multiple devices with the same address. I rather have these devices
> leave the kernel in unconfigured mode. And then force a userspace tool
> to use Set Public Address to bring it into configured mode.
>
The "new" property is optional and think that for devices that has not
been provisioned with a bd address the boot loader should not add this
property.
Base on the fact that the firmware is built with the assumption that the
host will set the bd address I think the patch should be amended to
specify HCI_QUIRK_INVALID_BDADDR in the absence of this property.
Regards,
Bjorn
^ permalink raw reply
* [PATCH nf-next 5/5] netfilter: nf_tables: support for recursive chain deletion
From: Pablo Neira Ayuso @ 2017-09-03 21:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1504475761-11454-1-git-send-email-pablo@netfilter.org>
This patch sorts out an asymmetry in deletions. Currently, table and set
deletion commands come with an implicit content flush on deletion.
However, chain deletion results in -EBUSY if there is content in this
chain, so no implicit flush happens. So you have to send a flush command
in first place to delete chains, this is inconsistent and it can be
annoying in terms of user experience.
This patch uses the new NLM_F_NONREC flag to request non-recursive chain
deletion, ie. if the chain to be removed contains rules, then this
returns EBUSY. This problem was discussed during the NFWS'17 in Faro,
Portugal. In iptables, you hit -EBUSY if you try to delete a chain that
contains rules, so you have to flush first before you can remove
anything. Since iptables-compat uses the nf_tables netlink interface, it
has to use the NLM_F_NONREC flag from userspace to retain the original
iptables semantics, ie. bail out on removing chains that contain rules.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_api.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 2ea043e5b344..5e2cfdbd51bd 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -1617,8 +1617,11 @@ static int nf_tables_delchain(struct net *net, struct sock *nlsk,
struct nft_af_info *afi;
struct nft_table *table;
struct nft_chain *chain;
+ struct nft_rule *rule;
int family = nfmsg->nfgen_family;
struct nft_ctx ctx;
+ u32 use;
+ int err;
afi = nf_tables_afinfo_lookup(net, family, false);
if (IS_ERR(afi))
@@ -1631,11 +1634,30 @@ static int nf_tables_delchain(struct net *net, struct sock *nlsk,
chain = nf_tables_chain_lookup(table, nla[NFTA_CHAIN_NAME], genmask);
if (IS_ERR(chain))
return PTR_ERR(chain);
- if (chain->use > 0)
+
+ if (nlh->nlmsg_flags & NLM_F_NONREC &&
+ chain->use > 0)
return -EBUSY;
nft_ctx_init(&ctx, net, skb, nlh, afi, table, chain, nla);
+ use = chain->use;
+ list_for_each_entry(rule, &chain->rules, list) {
+ if (!nft_is_active_next(net, rule))
+ continue;
+ use--;
+
+ err = nft_delrule(&ctx, rule);
+ if (err < 0)
+ return err;
+ }
+
+ /* There are rules and elements that are still holding references to us,
+ * we cannot do a recursive removal in this case.
+ */
+ if (use > 0)
+ return -EBUSY;
+
return nft_delchain(&ctx);
}
--
2.1.4
^ permalink raw reply related
* [PATCH nf-next 3/5] netlink: add NLM_F_NONREC flag for deletion requests
From: Pablo Neira Ayuso @ 2017-09-03 21:55 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In the last NFWS in Faro, Portugal, we discussed that netlink is lacking
the semantics to request non recursive deletions, ie. do not delete an
object iff it has child objects that hang from this parent object that
the user requests to be deleted.
We need this new flag to solve a problem for the iptables-compat
backward compatibility utility, that runs iptables commands using the
existing nf_tables netlink interface. Specifically, custom chains in
iptables cannot be deleted if there are rules in it, however, nf_tables
allows to remove any chain that is populated with content. To sort out
this asymmetry, iptables-compat userspace sets this new NLM_F_NONREC
flag to obtain the same semantics that iptables provides.
This new flag should only be used for deletion requests. Note this new
flag value overlaps with the existing:
* NLM_F_ROOT for get requests.
* NLM_F_REPLACE for new requests.
However, those flags should not ever be used in deletion requests.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
@David: Please, acknowledge this if you think this is fine so I can
take this into the nf-next tree, given patches 4/5 and 5/5
depend on this. Thanks a lot!
include/uapi/linux/netlink.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index f4fc9c9e123d..e8af60a7c56d 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -69,6 +69,9 @@ struct nlmsghdr {
#define NLM_F_CREATE 0x400 /* Create, if it does not exist */
#define NLM_F_APPEND 0x800 /* Add to end of list */
+/* Modifiers to DELETE request */
+#define NLM_F_NONREC 0x100 /* Do not delete recursively */
+
/* Flags for ACK message */
#define NLM_F_CAPPED 0x100 /* request was capped */
#define NLM_F_ACK_TLVS 0x200 /* extended ACK TVLs were included */
--
2.1.4
^ permalink raw reply related
* [PATCH nf-next 4/5] netfilter: nf_tables: use NLM_F_NONREC for deletion requests
From: Pablo Neira Ayuso @ 2017-09-03 21:56 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1504475761-11454-1-git-send-email-pablo@netfilter.org>
Bail out if user requests non-recursive deletion for tables and sets.
This new flags tells nf_tables netlink interface to reject deletions if
tables and sets have content.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_api.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 8b86acbb9770..2ea043e5b344 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -860,6 +860,10 @@ static int nf_tables_deltable(struct net *net, struct sock *nlsk,
if (IS_ERR(table))
return PTR_ERR(table);
+ if (nlh->nlmsg_flags & NLM_F_NONREC &&
+ table->use > 0)
+ return -EBUSY;
+
ctx.afi = afi;
ctx.table = table;
@@ -3225,7 +3229,9 @@ static int nf_tables_delset(struct net *net, struct sock *nlsk,
set = nf_tables_set_lookup(ctx.table, nla[NFTA_SET_NAME], genmask);
if (IS_ERR(set))
return PTR_ERR(set);
- if (!list_empty(&set->bindings))
+
+ if (!list_empty(&set->bindings) ||
+ (nlh->nlmsg_flags & NLM_F_NONREC && atomic_read(&set->nelems) > 0))
return -EBUSY;
return nft_delset(&ctx, set);
--
2.1.4
^ permalink raw reply related
* [PATCH 00/47] Netfilter updates for net-next
From: Pablo Neira Ayuso @ 2017-09-03 22:25 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter updates for your net-next
tree. Basically, updates to the conntrack core, enhancements for
nf_tables, conversion of netfilter hooks from linked list to array to
improve memory locality and asorted improvements for the Netfilter
codebase. More specifically, they are:
1) Add expection to hashes after timer initialization to prevent
access from another CPU that walks on the hashes and calls
del_timer(), from Florian Westphal.
2) Don't update nf_tables chain counters from hot path, this is only
used by the x_tables compatibility layer.
3) Get rid of nested rcu_read_lock() calls from netfilter hook path.
Hooks are always guaranteed to run from rcu read side, so remove
nested rcu_read_lock() where possible. Patch from Taehee Yoo.
4) nf_tables new ruleset generation notifications include PID and name
of the process that has updated the ruleset, from Phil Sutter.
5) Use skb_header_pointer() from nft_fib, so we can reuse this code from
the nf_family netdev family. Patch from Pablo M. Bermudo.
6) Add support for nft_fib in nf_tables netdev family, also from Pablo.
7) Use deferrable workqueue for conntrack garbage collection, to reduce
power consumption, from Patch from Subash Abhinov Kasiviswanathan.
8) Add nf_ct_expect_iterate_net() helper and use it. From Florian
Westphal.
9) Call nf_ct_unconfirmed_destroy only from cttimeout, from Florian.
10) Drop references on conntrack removal path when skbuffs has escaped via
nfqueue, from Florian.
11) Don't queue packets to nfqueue with dying conntrack, from Florian.
12) Constify nf_hook_ops structure, from Florian.
13) Remove neededlessly branch in nf_tables trace code, from Phil Sutter.
14) Add nla_strdup(), from Phil Sutter.
15) Rise nf_tables objects name size up to 255 chars, people want to use
DNS names, so increase this according to what RFC 1035 specifies.
Patch series from Phil Sutter.
16) Kill nf_conntrack_default_on, it's broken. Default on conntrack hook
registration on demand, suggested by Eric Dumazet, patch from Florian.
17) Remove unused variables in compat_copy_entry_from_user both in
ip_tables and arp_tables code. Patch from Taehee Yoo.
18) Constify struct nf_conntrack_l4proto, from Julia Lawall.
19) Constify nf_loginfo structure, also from Julia.
20) Use a single rb root in connlimit, from Taehee Yoo.
21) Remove unused netfilter_queue_init() prototype, from Taehee Yoo.
22) Use audit_log() instead of open-coding it, from Geliang Tang.
23) Allow to mangle tcp options via nft_exthdr, from Florian.
24) Allow to fetch TCP MSS from nft_rt, from Florian. This includes
a fix for a miscalculation of the minimal length.
25) Simplify branch logic in h323 helper, from Nick Desaulniers.
26) Calculate netlink attribute size for conntrack tuple at compile
time, from Florian.
27) Remove protocol name field from nf_conntrack_{l3,l4}proto structure.
From Florian.
28) Remove holes in nf_conntrack_l4proto structure, so it becomes
smaller. From Florian.
29) Get rid of print_tuple() indirection for /proc conntrack listing.
Place all the code in net/netfilter/nf_conntrack_standalone.c.
Patch from Florian.
30) Do not built in print_conntrack() if CONFIG_NF_CONNTRACK_PROCFS is
off. From Florian.
31) Constify most nf_conntrack_{l3,l4}proto helper functions, from
Florian.
32) Fix broken indentation in ebtables extensions, from Colin Ian King.
33) Fix several harmless sparse warning, from Florian.
34) Convert netfilter hook infrastructure to use array for better memory
locality, joint work done by Florian and Aaron Conole. Moreover, add
some instrumentation to debug this.
35) Batch nf_unregister_net_hooks() calls, to call synchronize_net once
per batch, from Florian.
36) Get rid of noisy logging in ICMPv6 conntrack helper, from Florian.
37) Get rid of obsolete NFDEBUG() instrumentation, from Varsha Rao.
38) Remove unused code in the generic protocol tracker, from Davide
Caratti.
I think I will have material for a second Netfilter batch in my queue if
time allow to make it fit in this merge window.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 7a68ada6ec7d88c68057d3a4c2a517eb94289976:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-07-21 03:38:43 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git HEAD
for you to fetch changes up to 1aff64715edb8565e99337b842d814d636641b50:
netfilter: rt: account for tcp header size too (2017-08-28 18:14:30 +0200)
----------------------------------------------------------------
Aaron Conole (1):
netfilter: convert hook list to an array
Colin Ian King (1):
netfilter: ebtables: fix indent on if statements
Davide Caratti (1):
netfilter: conntrack: remove unused code in nf_conntrack_proto_generic.c
Florian Westphal (24):
netfilter: expect: add to hash table after expect init
netfilter: expect: add and use nf_ct_expect_iterate helpers
netfilter: add and use nf_ct_unconfirmed_destroy
netfilter: conntrack: destroy functions need to free queued packets
netfilter: nfnetlink_queue: don't queue dying conntracks to userspace
netfilter: nf_hook_ops structs can be const
netfilter: nft_set_rbtree: use seqcount to avoid lock in most cases
netfilter: conntrack: do not enable connection tracking unless needed
netfilter: exthdr: factor out tcp option access
netfilter: exthdr: split netlink dump function
netfilter: exthdr: tcp option set support
netfilter: rt: add support to fetch path mss
netfilter: conntrack: compute l3proto nla size at compile time
netfilter: conntrack: remove protocol name from l3proto struct
netfilter: conntrack: remove protocol name from l4proto struct
netfilter: conntrack: reduce size of l4protocol trackers
netfilter: conntrack: place print_tuple in procfs part
netfilter: conntrack: print_conntrack only needed if CONFIG_NF_CONNTRACK_PROCFS
netfilter: conntrack: make protocol tracker pointers const
netfilter: fix a few (harmless) sparse warnings
netfilter: debug: check for sorted array
netfilter: core: batch nf_unregister_net_hooks synchronize_net calls
netfilter: conntrack: don't log "invalid" icmpv6 connections
netfilter: rt: account for tcp header size too
Geliang Tang (1):
netfilter: use audit_log()
Julia Lawall (2):
netfilter: constify nf_conntrack_l3/4proto parameters
netfilter: constify nf_loginfo structures
Nick Desaulniers (1):
netfilter: nf_nat_h323: fix logical-not-parentheses warning
Pablo M. Bermudo Garay (2):
netfilter: nf_tables: fib: use skb_header_pointer
netfilter: nf_tables: add fib expression to the netdev family
Pablo Neira Ayuso (1):
netfilter: nf_tables: keep chain counters away from hot path
Phil Sutter (7):
netfilter: nf_tables: Attach process info to NFT_MSG_NEWGEN notifications
netfilter: nf_tables: No need to check chain existence when tracing
netlink: Introduce nla_strdup()
netfilter: nf_tables: Allow table names of up to 255 chars
netfilter: nf_tables: Allow chain name of up to 255 chars
netfilter: nf_tables: Allow set names of up to 255 chars
netfilter: nf_tables: Allow object names of up to 255 chars
Subash Abhinov Kasiviswanathan (1):
netfilter: conntrack: Change to deferable work queue
Taehee Yoo (4):
netfilter: Remove duplicated rcu_read_lock.
netfilter: xtables: Remove unused variable in compat_copy_entry_from_user()
netfilter: connlimit: merge root4 and root6.
netfilter: remove prototype of netfilter_queue_init
Varsha Rao (1):
netfilter: Remove NFDEBUG()
Documentation/networking/nf_conntrack-sysctl.txt | 11 -
drivers/net/ipvlan/ipvlan_main.c | 2 +-
include/linux/netdevice.h | 2 +-
include/linux/netfilter.h | 45 +--
include/linux/netfilter_ingress.h | 4 +-
include/net/netfilter/nf_conntrack.h | 3 +
include/net/netfilter/nf_conntrack_expect.h | 5 +
include/net/netfilter/nf_conntrack_l3proto.h | 45 +--
include/net/netfilter/nf_conntrack_l4proto.h | 36 +--
include/net/netfilter/nf_conntrack_timeout.h | 4 +-
include/net/netfilter/nf_queue.h | 2 +-
include/net/netfilter/nf_tables.h | 10 +-
include/net/netfilter/nf_tables_core.h | 2 +
include/net/netlink.h | 1 +
include/net/netns/netfilter.h | 2 +-
include/uapi/linux/netfilter/nf_tables.h | 17 +-
lib/nlattr.c | 24 ++
net/bridge/br_netfilter_hooks.c | 21 +-
net/bridge/netfilter/ebt_ip.c | 4 +-
net/bridge/netfilter/ebt_ip6.c | 2 +-
net/bridge/netfilter/ebtable_filter.c | 2 +-
net/bridge/netfilter/ebtable_nat.c | 2 +-
net/bridge/netfilter/ebtables.c | 13 +-
net/decnet/netfilter/dn_rtmsg.c | 2 +-
net/ipv4/netfilter/arp_tables.c | 2 -
net/ipv4/netfilter/ip_tables.c | 4 +-
net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +-
net/ipv4/netfilter/ipt_SYNPROXY.c | 2 +-
net/ipv4/netfilter/iptable_nat.c | 2 +-
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 40 +--
net/ipv4/netfilter/nf_conntrack_proto_icmp.c | 12 -
net/ipv4/netfilter/nf_defrag_ipv4.c | 2 +-
net/ipv4/netfilter/nf_log_arp.c | 2 +-
net/ipv4/netfilter/nf_log_ipv4.c | 2 +-
net/ipv4/netfilter/nf_nat_h323.c | 57 ++--
net/ipv4/netfilter/nft_fib_ipv4.c | 20 +-
net/ipv6/ila/ila_xlat.c | 2 +-
net/ipv6/netfilter/ip6_tables.c | 2 +-
net/ipv6/netfilter/ip6t_SYNPROXY.c | 2 +-
net/ipv6/netfilter/ip6table_nat.c | 2 +-
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 42 +--
net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c | 17 --
net/ipv6/netfilter/nf_defrag_ipv6_hooks.c | 2 +-
net/ipv6/netfilter/nf_log_ipv6.c | 2 +-
net/ipv6/netfilter/nft_fib_ipv6.c | 29 +-
net/netfilter/Kconfig | 9 +
net/netfilter/Makefile | 1 +
net/netfilter/core.c | 351 +++++++++++++++++++----
net/netfilter/ipvs/ip_vs_core.c | 10 +-
net/netfilter/ipvs/ip_vs_ctl.c | 3 -
net/netfilter/ipvs/ip_vs_ftp.c | 2 -
net/netfilter/ipvs/ip_vs_proto_sctp.c | 11 +-
net/netfilter/ipvs/ip_vs_proto_tcp.c | 10 +-
net/netfilter/ipvs/ip_vs_proto_udp.c | 10 +-
net/netfilter/ipvs/ip_vs_xmit.c | 46 +--
net/netfilter/nf_conntrack_broadcast.c | 2 -
net/netfilter/nf_conntrack_core.c | 44 +--
net/netfilter/nf_conntrack_expect.c | 66 ++++-
net/netfilter/nf_conntrack_helper.c | 34 +--
net/netfilter/nf_conntrack_l3proto_generic.c | 7 -
net/netfilter/nf_conntrack_netlink.c | 106 +++----
net/netfilter/nf_conntrack_pptp.c | 2 -
net/netfilter/nf_conntrack_proto.c | 90 ++----
net/netfilter/nf_conntrack_proto_dccp.c | 18 +-
net/netfilter/nf_conntrack_proto_generic.c | 20 --
net/netfilter/nf_conntrack_proto_gre.c | 15 +-
net/netfilter/nf_conntrack_proto_sctp.c | 19 +-
net/netfilter/nf_conntrack_proto_tcp.c | 19 +-
net/netfilter/nf_conntrack_proto_udp.c | 17 --
net/netfilter/nf_conntrack_sip.c | 6 +-
net/netfilter/nf_conntrack_standalone.c | 97 ++++++-
net/netfilter/nf_internals.h | 10 +-
net/netfilter/nf_queue.c | 68 +++--
net/netfilter/nf_sockopt.c | 2 +-
net/netfilter/nf_tables_api.c | 128 ++++++---
net/netfilter/nf_tables_core.c | 28 +-
net/netfilter/nf_tables_trace.c | 42 ++-
net/netfilter/nfnetlink_cttimeout.c | 22 +-
net/netfilter/nfnetlink_log.c | 2 +-
net/netfilter/nfnetlink_queue.c | 21 +-
net/netfilter/nft_exthdr.c | 213 ++++++++++++--
net/netfilter/nft_fib_netdev.c | 87 ++++++
net/netfilter/nft_payload.c | 2 +-
net/netfilter/nft_rt.c | 73 ++++-
net/netfilter/nft_set_rbtree.c | 49 +++-
net/netfilter/x_tables.c | 14 +-
net/netfilter/xt_CT.c | 2 +-
net/netfilter/xt_TCPMSS.c | 2 -
net/netfilter/xt_TPROXY.c | 4 -
net/netfilter/xt_addrtype.c | 3 -
net/netfilter/xt_connlimit.c | 26 +-
net/netfilter/xt_hashlimit.c | 8 +-
net/netfilter/xt_osf.c | 2 -
net/openvswitch/conntrack.c | 4 +-
security/selinux/hooks.c | 2 +-
security/smack/smack_netfilter.c | 2 +-
96 files changed, 1443 insertions(+), 896 deletions(-)
create mode 100644 net/netfilter/nft_fib_netdev.c
^ permalink raw reply
* [PATCH 02/47] netfilter: nf_tables: keep chain counters away from hot path
From: Pablo Neira Ayuso @ 2017-09-03 22:25 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1504477589-12045-1-git-send-email-pablo@netfilter.org>
These chain counters are only used by the iptables-compat tool, that
allow users to use the x_tables extensions from the existing nf_tables
framework. This patch makes nf_tables by ~5% for the general usecase,
ie. native nft users, where no chain counters are used at all.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/netfilter/nf_tables_core.h | 2 ++
net/netfilter/nf_tables_api.c | 11 +++--------
net/netfilter/nf_tables_core.c | 26 ++++++++++++++++++--------
3 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/include/net/netfilter/nf_tables_core.h b/include/net/netfilter/nf_tables_core.h
index 8f690effec37..424684c33771 100644
--- a/include/net/netfilter/nf_tables_core.h
+++ b/include/net/netfilter/nf_tables_core.h
@@ -49,6 +49,8 @@ struct nft_payload_set {
};
extern const struct nft_expr_ops nft_payload_fast_ops;
+
+extern struct static_key_false nft_counters_enabled;
extern struct static_key_false nft_trace_enabled;
#endif /* _NET_NF_TABLES_CORE_H */
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 7843efa33c59..7fbf0070aba1 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -1240,6 +1240,8 @@ static void nf_tables_chain_destroy(struct nft_chain *chain)
module_put(basechain->type->owner);
free_percpu(basechain->stats);
+ if (basechain->stats)
+ static_branch_dec(&nft_counters_enabled);
if (basechain->ops[0].dev != NULL)
dev_put(basechain->ops[0].dev);
kfree(basechain);
@@ -1504,14 +1506,7 @@ static int nf_tables_newchain(struct net *net, struct sock *nlsk,
return PTR_ERR(stats);
}
basechain->stats = stats;
- } else {
- stats = netdev_alloc_pcpu_stats(struct nft_stats);
- if (stats == NULL) {
- nft_chain_release_hook(&hook);
- kfree(basechain);
- return -ENOMEM;
- }
- rcu_assign_pointer(basechain->stats, stats);
+ static_branch_inc(&nft_counters_enabled);
}
hookfn = hook.type->hooks[hook.num];
diff --git a/net/netfilter/nf_tables_core.c b/net/netfilter/nf_tables_core.c
index 65dbeadcb118..c5bab08b0d73 100644
--- a/net/netfilter/nf_tables_core.c
+++ b/net/netfilter/nf_tables_core.c
@@ -114,6 +114,22 @@ static bool nft_payload_fast_eval(const struct nft_expr *expr,
return true;
}
+DEFINE_STATIC_KEY_FALSE(nft_counters_enabled);
+
+static noinline void nft_update_chain_stats(const struct nft_chain *chain,
+ const struct nft_pktinfo *pkt)
+{
+ struct nft_stats *stats;
+
+ local_bh_disable();
+ stats = this_cpu_ptr(rcu_dereference(nft_base_chain(chain)->stats));
+ u64_stats_update_begin(&stats->syncp);
+ stats->pkts++;
+ stats->bytes += pkt->skb->len;
+ u64_stats_update_end(&stats->syncp);
+ local_bh_enable();
+}
+
struct nft_jumpstack {
const struct nft_chain *chain;
const struct nft_rule *rule;
@@ -130,7 +146,6 @@ nft_do_chain(struct nft_pktinfo *pkt, void *priv)
struct nft_regs regs;
unsigned int stackptr = 0;
struct nft_jumpstack jumpstack[NFT_JUMP_STACK_SIZE];
- struct nft_stats *stats;
int rulenum;
unsigned int gencursor = nft_genmask_cur(net);
struct nft_traceinfo info;
@@ -220,13 +235,8 @@ nft_do_chain(struct nft_pktinfo *pkt, void *priv)
nft_trace_packet(&info, basechain, NULL, -1,
NFT_TRACETYPE_POLICY);
- rcu_read_lock_bh();
- stats = this_cpu_ptr(rcu_dereference(nft_base_chain(basechain)->stats));
- u64_stats_update_begin(&stats->syncp);
- stats->pkts++;
- stats->bytes += pkt->skb->len;
- u64_stats_update_end(&stats->syncp);
- rcu_read_unlock_bh();
+ if (static_branch_unlikely(&nft_counters_enabled))
+ nft_update_chain_stats(basechain, pkt);
return nft_base_chain(basechain)->policy;
}
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox