* [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 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 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
* 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
* 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][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][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 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: [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: [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: [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: 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 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
* [PATCH net-next] bridge: switchdev: Use an helper to clear forward mark
From: Ido Schimmel @ 2017-09-03 14:44 UTC (permalink / raw)
To: netdev; +Cc: davem, stephen, nikolay, yotamg, bridge, mlxsw, Ido Schimmel
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(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 5a7be3bddfa9..f6b6a92f1c48 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -53,9 +53,7 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
brstats->tx_bytes += skb->len;
u64_stats_update_end(&brstats->syncp);
-#ifdef CONFIG_NET_SWITCHDEV
- skb->offload_fwd_mark = 0;
-#endif
+ br_switchdev_frame_unmark(skb);
BR_INPUT_SKB_CB(skb)->brdev = dev;
skb_reset_mac_header(skb);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index fd9ee73e0a6d..e870cfc85b14 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -1091,6 +1091,11 @@ int br_switchdev_set_port_flag(struct net_bridge_port *p,
unsigned long mask);
void br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb,
int type);
+
+static inline void br_switchdev_frame_unmark(struct sk_buff *skb)
+{
+ skb->offload_fwd_mark = 0;
+}
#else
static inline int nbp_switchdev_mark_set(struct net_bridge_port *p)
{
@@ -1119,6 +1124,10 @@ static inline void
br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb, int type)
{
}
+
+static inline void br_switchdev_frame_unmark(struct sk_buff *skb)
+{
+}
#endif /* CONFIG_NET_SWITCHDEV */
#endif
--
2.13.5
^ permalink raw reply related
* [PATCH] dt-binding: phy: don't confuse with Ethernet phy properties
From: Baruch Siach @ 2017-09-03 14:32 UTC (permalink / raw)
To: Kishon Vijay Abraham I; +Cc: linux-kernel, netdev, Baruch Siach
The generic PHY 'phys' property sometime appears in the same node with
the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in
phy-bindings.txt to reduce confusion.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Documentation/devicetree/bindings/phy/phy-bindings.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
index 1293c321754c..a403b81d0679 100644
--- a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -34,7 +34,9 @@ PHY user node
=============
Required Properties:
-phys : the phandle for the PHY device (used by the PHY subsystem)
+phys : the phandle for the PHY device (used by the PHY subsystem; not to be
+ confused with the Ethernet specific 'phy' and 'phy-handle' properties,
+ see Documentation/devicetree/bindings/net/ethernet.txt for these)
phy-names : the names of the PHY corresponding to the PHYs present in the
*phys* phandle
--
2.14.1
^ permalink raw reply related
* Re: [PATCH 7/10] net/mlx4_core: Use ARRAY_SIZE macro
From: Tariq Toukan @ 2017-09-03 13:14 UTC (permalink / raw)
To: Thomas Meyer, netdev, linux-rdma, linux-kernel
In-Reply-To: <1504439110050-1961876957-7-diffsplit-thomas@m3y3r.de>
On 03/09/2017 3:19 PM, Thomas Meyer wrote:
> Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
> yourself.
> Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
> 's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
> /ARRAY_SIZE(\1)/g' and manual check/verification.
>
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> ---
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Thanks Thomas!
^ permalink raw reply
* [PATCH] geneve: Fix setting ttl value in collect metadata mode
From: Haishuang Yan @ 2017-09-03 12:49 UTC (permalink / raw)
To: David S. Miller, pravin shelar, Girish Moodalbail
Cc: netdev, linux-kernel, Haishuang Yan
If key->tos is zero in collect metadata mode, tos should fallback to
ip{4,6}_dst_hoplimit, same as normal mode.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
drivers/net/geneve.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index f640407..d52a65f 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -834,11 +834,10 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
if (geneve->collect_md) {
tos = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
- ttl = key->ttl;
} else {
tos = ip_tunnel_ecn_encap(fl4.flowi4_tos, ip_hdr(skb), skb);
- ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
}
+ ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
err = geneve_build_skb(&rt->dst, skb, info, xnet, sizeof(struct iphdr));
@@ -873,12 +872,11 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
if (geneve->collect_md) {
prio = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
- ttl = key->ttl;
} else {
prio = ip_tunnel_ecn_encap(ip6_tclass(fl6.flowlabel),
ip_hdr(skb), skb);
- ttl = key->ttl ? : ip6_dst_hoplimit(dst);
}
+ ttl = key->ttl ? : ip6_dst_hoplimit(dst);
err = geneve_build_skb(dst, skb, info, xnet, sizeof(struct ipv6hdr));
if (unlikely(err))
return err;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: add SFF vendor prefix
From: Baruch Siach @ 2017-09-03 12:31 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S. Miller, Russell King
Cc: netdev, devicetree, Sergei Shtylyov, Baruch Siach
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v3: Add Rob's ack
v2: New patch in this series
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index daf465bef758..20fdb79a92d4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -287,6 +287,7 @@ schindler Schindler
seagate Seagate Technology PLC
semtech Semtech Corporation
sensirion Sensirion AG
+sff Small Form Factor Committee
sgx SGX Sensortech
sharp Sharp Corporation
si-en Si-En Technology Ltd.
--
2.14.1
^ permalink raw reply related
* [PATCH v3 3/3] net: phy: sfp: rename the rate-select property
From: Baruch Siach @ 2017-09-03 12:31 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S. Miller, Russell King
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Sergei Shtylyov, Baruch Siach
In-Reply-To: <c2a27566a8eb358ee2566a213c385d0bf3d64307.1504441874.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Make the Rx rate select control gpio property name match the documented
binding. This would make the addition of 'rate-select1-gpios' for SFP+
support more natural.
Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
---
v3: No change
v2: New patch in this series
---
drivers/net/phy/sfp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index fb2cf4342f48..b44c0e296662 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -62,7 +62,7 @@ static const char *gpio_of_names[] = {
"los",
"tx-fault",
"tx-disable",
- "rate-select",
+ "rate-select0",
};
static const enum gpiod_flags gpio_flags[] = {
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 related
* [PATCH v3 2/3] dt-binding: net: sfp binding documentation
From: Baruch Siach @ 2017-09-03 12:31 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S. Miller, Russell King
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Sergei Shtylyov, Baruch Siach
In-Reply-To: <c2a27566a8eb358ee2566a213c385d0bf3d64307.1504441874.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
---
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>;
+ sfp = <&sfp_eth3>;
+};
+
+Example #2: Serdes to PHY to SFP connection
+
+sfp_eth0: sfp-eth0 {
+ compatible = "sff,sfp+";
+ i2c-bus = <&sfpp0_i2c>;
+ los-gpios = <&cps_gpio1 28 GPIO_ACTIVE_HIGH>;
+ moddef0-gpios = <&cps_gpio1 27 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cps_sfpp0_pins>;
+ tx-disable-gpios = <&cps_gpio1 29 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpios = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>;
+};
+
+p0_phy: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ pinctrl-names = "default";
+ pinctrl-0 = <&cpm_phy0_pins &cps_phy0_pins>;
+ reg = <0>;
+ interrupt = <&cpm_gpio2 18 IRQ_TYPE_EDGE_FALLING>;
+ sfp = <&sfp_eth0>;
+};
+
+&cpm_eth0 {
+ phy = <&p0_phy>;
+ phy-mode = "10gbase-kr";
+};
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 related
* [PATCH 8/10] ath9k: Use ARRAY_SIZE macro
From: Thomas Meyer @ 2017-09-03 12:19 UTC (permalink / raw)
To: kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1504439110050-939061377-0-diffsplit-thomas@m3y3r.de>
Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 3dbfd86ebe36..c2e210c0a770 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -15,6 +15,7 @@
*/
#include <asm/unaligned.h>
+#include <linux/kernel.h>
#include "hw.h"
#include "ar9003_phy.h"
#include "ar9003_eeprom.h"
@@ -2946,14 +2947,12 @@ static const struct ar9300_eeprom *ar9300_eep_templates[] = {
static const struct ar9300_eeprom *ar9003_eeprom_struct_find_by_id(int id)
{
-#define N_LOOP (sizeof(ar9300_eep_templates) / sizeof(ar9300_eep_templates[0]))
int it;
- for (it = 0; it < N_LOOP; it++)
+ for (it = 0; it < ARRAY_SIZE(ar9300_eep_templates); it++)
if (ar9300_eep_templates[it]->templateVersion == id)
return ar9300_eep_templates[it];
return NULL;
-#undef N_LOOP
}
static int ath9k_hw_ar9300_check_eeprom(struct ath_hw *ah)
^ permalink raw reply related
* [PATCH 6/10] ixgbe: Use ARRAY_SIZE macro
From: Thomas Meyer @ 2017-09-03 12:19 UTC (permalink / raw)
To: netdev, linux-kernel
In-Reply-To: <1504439110050-939061377-0-diffsplit-thomas@m3y3r.de>
Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index 72d84a065e34..fabb11475fb4 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -21,6 +21,7 @@
* Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
*
******************************************************************************/
+#include <linux/kernel.h>
#include "ixgbe_x540.h"
#include "ixgbe_type.h"
#include "ixgbe_common.h"
@@ -947,7 +948,7 @@ static s32 ixgbe_checksum_ptr_x550(struct ixgbe_hw *hw, u16 ptr,
u16 length, bufsz, i, start;
u16 *local_buffer;
- bufsz = sizeof(buf) / sizeof(buf[0]);
+ bufsz = ARRAY_SIZE(buf);
/* Read a chunk at the pointer location */
if (!buffer) {
^ permalink raw reply related
* [PATCH 7/10] net/mlx4_core: Use ARRAY_SIZE macro
From: Thomas Meyer @ 2017-09-03 12:19 UTC (permalink / raw)
To: netdev, linux-rdma, linux-kernel
In-Reply-To: <1504439110050-939061377-0-diffsplit-thomas@m3y3r.de>
Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 041c0ed65929..8eca12927be0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -36,6 +36,7 @@
#include <linux/mlx4/cmd.h>
#include <linux/module.h>
#include <linux/cache.h>
+#include <linux/kernel.h>
#include "fw.h"
#include "icm.h"
@@ -2450,14 +2451,14 @@ int mlx4_config_dev_retrieval(struct mlx4_dev *dev,
csum_mask = (config_dev.rx_checksum_val >> CONFIG_DEV_RX_CSUM_MODE_PORT1_BIT_OFFSET) &
CONFIG_DEV_RX_CSUM_MODE_MASK;
- if (csum_mask >= sizeof(config_dev_csum_flags)/sizeof(config_dev_csum_flags[0]))
+ if (csum_mask >= ARRAY_SIZE(config_dev_csum_flags))
return -EINVAL;
params->rx_csum_flags_port_1 = config_dev_csum_flags[csum_mask];
csum_mask = (config_dev.rx_checksum_val >> CONFIG_DEV_RX_CSUM_MODE_PORT2_BIT_OFFSET) &
CONFIG_DEV_RX_CSUM_MODE_MASK;
- if (csum_mask >= sizeof(config_dev_csum_flags)/sizeof(config_dev_csum_flags[0]))
+ if (csum_mask >= ARRAY_SIZE(config_dev_csum_flags))
return -EINVAL;
params->rx_csum_flags_port_2 = config_dev_csum_flags[csum_mask];
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 5fe5cdc51357..fe18650c9342 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -34,6 +34,7 @@
*/
#include <linux/module.h>
+#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/pci.h>
@@ -3658,7 +3659,7 @@ static int __mlx4_init_one(struct pci_dev *pdev, int pci_dev_data,
* per port, we must limit the number of VFs to 63 (since their are
* 128 MACs)
*/
- for (i = 0; i < sizeof(nvfs)/sizeof(nvfs[0]) && i < num_vfs_argc;
+ for (i = 0; i < ARRAY_SIZE(nvfs) && i < num_vfs_argc;
total_vfs += nvfs[param_map[num_vfs_argc - 1][i]], i++) {
nvfs[param_map[num_vfs_argc - 1][i]] = num_vfs[i];
if (nvfs[i] < 0) {
@@ -3667,7 +3668,7 @@ static int __mlx4_init_one(struct pci_dev *pdev, int pci_dev_data,
goto err_disable_pdev;
}
}
- for (i = 0; i < sizeof(prb_vf)/sizeof(prb_vf[0]) && i < probe_vfs_argc;
+ for (i = 0; i < ARRAY_SIZE(prb_vf) && i < probe_vfs_argc;
i++) {
prb_vf[param_map[probe_vfs_argc - 1][i]] = probe_vf[i];
if (prb_vf[i] < 0 || prb_vf[i] > nvfs[i]) {
@@ -3746,11 +3747,11 @@ static int __mlx4_init_one(struct pci_dev *pdev, int pci_dev_data,
if (total_vfs) {
unsigned vfs_offset = 0;
- for (i = 0; i < sizeof(nvfs)/sizeof(nvfs[0]) &&
+ for (i = 0; i < ARRAY_SIZE(nvfs) &&
vfs_offset + nvfs[i] < extended_func_num(pdev);
vfs_offset += nvfs[i], i++)
;
- if (i == sizeof(nvfs)/sizeof(nvfs[0])) {
+ if (i == ARRAY_SIZE(nvfs)) {
err = -ENODEV;
goto err_release_regions;
}
^ permalink raw reply related
* Re: [PATCH][next] net/mlx4_core: fix incorrect size allocation for dev->caps.spec_qps
From: Tariq Toukan @ 2017-09-03 7:28 UTC (permalink / raw)
To: Colin King, Tariq Toukan, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170831170724.3747-1-colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
On 31/08/2017 8:07 PM, Colin King wrote:
> 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>
> ---
> drivers/net/ethernet/mellanox/mlx4/qp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/qp.c b/drivers/net/ethernet/mellanox/mlx4/qp.c
> index b16fc441609e..728a2fb1f5c0 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/qp.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
> @@ -845,8 +845,9 @@ int mlx4_init_qp_table(struct mlx4_dev *dev)
>
> /* In mfunc, calculate proxy and tunnel qp offsets for the PF here,
> * since the PF does not call mlx4_slave_caps */
> - dev->caps.spec_qps = kcalloc(dev->caps.num_ports, sizeof(dev->caps.spec_qps), GFP_KERNEL);
> -
> + dev->caps.spec_qps = kcalloc(dev->caps.num_ports,
> + sizeof(*dev->caps.spec_qps),
> + GFP_KERNEL);
> if (!dev->caps.spec_qps) {
> err = -ENOMEM;
> goto err_mem;
>
Acked-by: Tariq Toukan <tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Thanks!
--
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][next] net/mlx4_core: fix memory leaks on error exit path
From: Tariq Toukan @ 2017-09-03 7:19 UTC (permalink / raw)
To: Colin King, Tariq Toukan, netdev, linux-rdma
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20170831163053.2349-1-colin.king@canonical.com>
On 31/08/2017 7:30 PM, Colin King wrote:
> 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>
> ---
> drivers/net/ethernet/mellanox/mlx4/main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
> index 1c92101b3ec2..d46f3283ec36 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
> @@ -977,7 +977,8 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
> if (dev->caps.num_ports > MLX4_MAX_PORTS) {
> mlx4_err(dev, "HCA has %d ports, but we only support %d, aborting\n",
> dev->caps.num_ports, MLX4_MAX_PORTS);
> - return -ENODEV;
> + err = -ENODEV;
> + goto free_mem;
> }
>
> mlx4_replace_zero_macs(dev);
>
Acked-by: Tariq Toukan <tariqt@mellanox.com>
Thanks Colin!
^ permalink raw reply
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