* pull-request: bpf-next 2018-10-21
From: Daniel Borkmann @ 2018-10-21 19:24 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) Implement two new kind of BPF maps, that is, queue and stack
map along with new peek, push and pop operations, from Mauricio.
2) Add support for MSG_PEEK flag when redirecting into an ingress
psock sk_msg queue, and add a new helper bpf_msg_push_data() for
insert data into the message, from John.
3) Allow for BPF programs of type BPF_PROG_TYPE_CGROUP_SKB to use
direct packet access for __skb_buff, from Song.
4) Use more lightweight barriers for walking perf ring buffer for
libbpf and perf tool as well. Also, various fixes and improvements
from verifier side, from Daniel.
5) Add per-symbol visibility for DSO in libbpf and hide by default
global symbols such as netlink related functions, from Andrey.
6) Two improvements to nfp's BPF offload to check vNIC capabilities
in case prog is shared with multiple vNICs and to protect against
mis-initializing atomic counters, from Jakub.
7) Fix for bpftool to use 4 context mode for the nfp disassembler,
also from Jakub.
8) Fix a return value comparison in test_libbpf.sh and add several
bpftool improvements in bash completion, documentation of bpf fs
restrictions and batch mode summary print, from Quentin.
9) Fix a file resource leak in BPF selftest's load_kallsyms()
helper, from Peng.
10) Fix an unused variable warning in map_lookup_and_delete_elem(),
from Alexei.
11) Fix bpf_skb_adjust_room() signature in BPF UAPI helper doc,
from Nicolas.
12) Add missing executables to .gitignore in BPF selftests, from Anders.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 2c59f06cc0442862d589c36bd2f29667f96c35e7:
Merge branch 'net-Kernel-side-filtering-for-route-dumps' (2018-10-16 00:14:18 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to fe8ecccc10b3adc071de05ca7af728ca1a4ac9aa:
tools: bpftool: fix completion for "bpftool map update" (2018-10-21 20:45:14 +0200)
----------------------------------------------------------------
Alexei Starovoitov (6):
Merge branch 'nfp-improve-bpf-offload'
Merge branch 'queue_stack_maps'
Merge branch 'improve_perf_barriers'
Merge branch 'cg_skb_direct_pkt_access'
bpf: remove unused variable
Merge branch 'misc-improvements'
Anders Roxell (1):
selftests/bpf: add missing executables to .gitignore
Andrey Ignatov (1):
libbpf: Per-symbol visibility for DSO
Daniel Borkmann (11):
bpf, tls: add tls header to tools infrastructure
Merge branch 'bpf-sk-msg-peek'
tools, perf: add and use optimized ring_buffer_{read_head, write_tail} helpers
bpf, libbpf: use correct barriers in perf ring buffer walk
Merge branch 'bpf-msg-push-data'
ulp: remove uid and user_visible members
bpf, verifier: fix register type dump in xadd and st
bpf, verifier: reject xadd on flow key memory
bpf, verifier: remove unneeded flow key in check_helper_mem_access
bpf, verifier: avoid retpoline for map push/pop/peek operation
bpf, libbpf: simplify and cleanup perf ring buffer walk
Jakub Kicinski (3):
nfp: bpf: protect against mis-initializing atomic counters
nfp: bpf: double check vNIC capabilities after object sharing
tools: bpftool: use 4 context mode for the NFP disasm
John Fastabend (8):
bpf: sockmap, fix skmsg recvmsg handler to track size correctly
bpf: skmsg, improve sk_msg_used_element to work in cork context
bpf: sockmap, support for msg_peek in sk_msg with redirect ingress
bpf: sockmap, add msg_peek tests to test_sockmap
bpf: skmsg, fix psock create on existing kcm/tls port
bpf: sk_msg program helper bpf_msg_push_data
bpf: libbpf support for msg_push_data
bpf: test_sockmap add options to use msg_push_data
Mauricio Vasquez B (7):
bpf: rename stack trace map operations
bpf/syscall: allow key to be null in map functions
bpf/verifier: add ARG_PTR_TO_UNINIT_MAP_VALUE
bpf: add queue and stack maps
bpf: add MAP_LOOKUP_AND_DELETE_ELEM syscall
Sync uapi/bpf.h to tools/include
selftests/bpf: add test cases for queue and stack maps
Nicolas Dichtel (1):
bpf: fix doc of bpf_skb_adjust_room() in uapi
Peng Hao (1):
selftests/bpf: fix file resource leak in load_kallsyms
Quentin Monnet (4):
selftests/bpf: fix return value comparison for tests in test_libbpf.sh
tools: bpftool: document restriction on '.' in names to pin in bpffs
tools: bpftool: print nb of cmds to stdout (not stderr) for batch mode
tools: bpftool: fix completion for "bpftool map update"
Song Liu (2):
bpf: add cg_skb_is_valid_access for BPF_PROG_TYPE_CGROUP_SKB
bpf: add tests for direct packet access from CGROUP_SKB
drivers/net/ethernet/netronome/nfp/bpf/main.h | 10 +-
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 32 ++-
drivers/net/ethernet/netronome/nfp/bpf/verifier.c | 69 ++++-
include/linux/bpf.h | 7 +
include/linux/bpf_types.h | 4 +-
include/linux/filter.h | 21 ++
include/linux/skmsg.h | 42 ++-
include/net/tcp.h | 9 +-
include/uapi/linux/bpf.h | 50 +++-
kernel/bpf/Makefile | 2 +-
kernel/bpf/cgroup.c | 6 +
kernel/bpf/core.c | 3 +
kernel/bpf/helpers.c | 43 +++
kernel/bpf/queue_stack_maps.c | 288 +++++++++++++++++++++
kernel/bpf/stackmap.c | 2 +-
kernel/bpf/syscall.c | 91 ++++++-
kernel/bpf/verifier.c | 85 +++++-
net/bpf/test_run.c | 15 ++
net/core/filter.c | 176 ++++++++++++-
net/core/sock_map.c | 11 +-
net/ipv4/tcp_bpf.c | 41 ++-
net/tls/tls_main.c | 2 -
net/tls/tls_sw.c | 3 +-
tools/arch/arm64/include/asm/barrier.h | 70 +++++
tools/arch/ia64/include/asm/barrier.h | 13 +
tools/arch/powerpc/include/asm/barrier.h | 16 ++
tools/arch/s390/include/asm/barrier.h | 13 +
tools/arch/sparc/include/asm/barrier_64.h | 13 +
tools/arch/x86/include/asm/barrier.h | 14 +
tools/bpf/bpftool/Documentation/bpftool-map.rst | 4 +-
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 8 +-
tools/bpf/bpftool/bash-completion/bpftool | 2 +-
tools/bpf/bpftool/common.c | 5 +-
tools/bpf/bpftool/jit_disasm.c | 4 +-
tools/bpf/bpftool/main.c | 3 +-
tools/bpf/bpftool/main.h | 6 +-
tools/bpf/bpftool/map_perf_ring.c | 10 +-
tools/bpf/bpftool/prog.c | 14 +-
tools/include/asm/barrier.h | 35 +++
tools/include/linux/ring_buffer.h | 73 ++++++
tools/include/uapi/linux/bpf.h | 50 +++-
tools/include/uapi/linux/tls.h | 78 ++++++
tools/lib/bpf/Makefile | 1 +
tools/lib/bpf/bpf.c | 12 +
tools/lib/bpf/bpf.h | 120 +++++----
tools/lib/bpf/btf.h | 22 +-
tools/lib/bpf/libbpf.c | 75 +++---
tools/lib/bpf/libbpf.h | 191 +++++++-------
tools/perf/util/mmap.h | 15 +-
tools/testing/selftests/bpf/.gitignore | 2 +
tools/testing/selftests/bpf/Makefile | 5 +-
tools/testing/selftests/bpf/bpf_helpers.h | 9 +
tools/testing/selftests/bpf/test_libbpf.sh | 2 +-
tools/testing/selftests/bpf/test_maps.c | 122 +++++++++
tools/testing/selftests/bpf/test_progs.c | 99 +++++++
tools/testing/selftests/bpf/test_queue_map.c | 4 +
tools/testing/selftests/bpf/test_queue_stack_map.h | 59 +++++
tools/testing/selftests/bpf/test_sockmap.c | 238 ++++++++++++-----
tools/testing/selftests/bpf/test_sockmap_kern.h | 97 +++++--
tools/testing/selftests/bpf/test_stack_map.c | 4 +
tools/testing/selftests/bpf/test_verifier.c | 181 ++++++++++++-
tools/testing/selftests/bpf/trace_helpers.c | 8 +-
62 files changed, 2315 insertions(+), 394 deletions(-)
create mode 100644 kernel/bpf/queue_stack_maps.c
create mode 100644 tools/include/linux/ring_buffer.h
create mode 100644 tools/include/uapi/linux/tls.h
create mode 100644 tools/testing/selftests/bpf/test_queue_map.c
create mode 100644 tools/testing/selftests/bpf/test_queue_stack_map.h
create mode 100644 tools/testing/selftests/bpf/test_stack_map.c
^ permalink raw reply
* Re: [PATCH iproute2-next 3/3] rdma: Add an option to rename IB device interface
From: David Ahern @ 2018-10-21 16:02 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20181018115120.17893-4-leon@kernel.org>
On 10/18/18 5:51 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Enrich rdmatool with an option to rename IB devices,
> the command interface follows Iproute2 convention:
> "rdma dev set [OLD-DEVNAME] name NEW-DEVNAME"
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/dev.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/rdma/dev.c b/rdma/dev.c
> index e2eafe47..760b7fb3 100644
> --- a/rdma/dev.c
> +++ b/rdma/dev.c
> @@ -14,6 +14,7 @@
> static int dev_help(struct rd *rd)
> {
> pr_out("Usage: %s dev show [DEV]\n", rd->filename);
> + pr_out(" %s dev set [DEV] name DEVNAME\n", rd->filename);
> return 0;
> }
>
> @@ -240,17 +241,51 @@ static int dev_one_show(struct rd *rd)
> return rd_exec_cmd(rd, cmds, "parameter");
> }
>
> +static int dev_set_name(struct rd *rd)
> +{
> + uint32_t seq;
> +
> + if (rd_no_arg(rd)) {
> + pr_err("Please provide device new name.\n");
> + return -EINVAL;
> + }
This is redundant with rd_exec_require_dev which is the required path to
get to this point.
^ permalink raw reply
* Re: [PATCHv2 iproute2-next] ip/geneve: fix ttl inherit behavior
From: David Ahern @ 2018-10-21 15:55 UTC (permalink / raw)
To: Hangbin Liu, netdev; +Cc: Stephen Hemminger, Phil Sutter, Michal Kubecek
In-Reply-To: <1539846110-11607-1-git-send-email-liuhangbin@gmail.com>
On 10/18/18 1:01 AM, Hangbin Liu wrote:
> Currently when we add geneve with "ttl inherit", we only set ttl to 0, which
> is actually use whatever default value instead of inherit the inner protocol's
> ttl value.
>
> To make a difference with ttl inherit and ttl == 0, we add an attribute
> IFLA_GENEVE_TTL_INHERIT in kernel commit 52d0d404d39dd ("geneve: add ttl
> inherit support"). Now let's use "ttl inherit" to inherit the inner
> protocol's ttl, and use "ttl auto" to means "use whatever default value",
> the same behavior with ttl == 0.
>
> v2:
> 1) remove IFLA_GENEVE_TTL_INHERIT defination in if_link.h as it's already
> updated.
> 2) Still use addattr8() so we can enable/disable ttl inherit, as Michal
> suggested.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> ip/iplink_geneve.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
please update the man page as well.
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: enable (uncomment) all tests in test_libbpf.sh
From: Quentin Monnet @ 2018-10-21 15:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, oss-drivers,
Quentin Monnet
In-Reply-To: <20181021115729.2095d2a0@redhat.com>
2018-10-21 11:57 UTC+0200 ~ Jesper Dangaard Brouer <brouer@redhat.com>
> On Sat, 20 Oct 2018 23:00:24 +0100
> Quentin Monnet <quentin.monnet@netronome.com> wrote:
>
[...]
>> --- a/tools/testing/selftests/bpf/test_libbpf.sh
>> +++ b/tools/testing/selftests/bpf/test_libbpf.sh
>> @@ -33,17 +33,11 @@ trap exit_handler 0 2 3 6 9
>>
>> libbpf_open_file test_l4lb.o
>>
>> -# TODO: fix libbpf to load noinline functions
>> -# [warning] libbpf: incorrect bpf_call opcode
>> -#libbpf_open_file test_l4lb_noinline.o
>> +libbpf_open_file test_l4lb_noinline.o
>>
>> -# TODO: fix test_xdp_meta.c to load with libbpf
>> -# [warning] libbpf: test_xdp_meta.o doesn't provide kernel version
>> -#libbpf_open_file test_xdp_meta.o
>> +libbpf_open_file test_xdp_meta.o
>>
>> -# TODO: fix libbpf to handle .eh_frame
>> -# [warning] libbpf: relocation failed: no section(10)
>> -#libbpf_open_file ../../../../samples/bpf/tracex3_kern.o
>> +libbpf_open_file ../../../../samples/bpf/tracex3_kern.o
>
> I don't like the ../../../../samples/bpf/ reference (even-through I
> added this TODO), as the kselftests AFAIK support installing the
> selftests and then this tests will fail.
> Maybe we can find another example kern.o file?
> (which isn't compiled with -target bpf)
Hi Jesper, yeah maybe making the test rely on something from samples/bpf
instead of just the selftests/bpf directory is not a good idea. But
there is no program compiled without the "-target-bpf" in that
directory. What we could do is explicitly compile one without the flag
in the Makefile, as in the patch below, but I am not sure that doing so
is acceptable? Or should tests for libbpf have a directory of their own,
with another Makefile?
Another question regarding the test with test_xdp_meta.o: does the fix I
suggested (setting a version in the .C file) makes sense, or did you
leave this test for testing someday that libbpf would be able to open
even programs that do not set a version (in which case this is still not
the case if program type is not provided, and in fact my fix ruins
everything? :s).
Thanks,
Quentin
---
tools/testing/selftests/bpf/Makefile | 10 ++++++++++
tools/testing/selftests/bpf/test_libbpf.sh | 14 +++++---------
tools/testing/selftests/bpf/test_xdp_meta.c | 2 ++
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index e39dfb4e7970..ecd79b7fb107 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -135,6 +135,16 @@ endif
endif
endif
+# Have one program compiled without "-target bpf" to test whether libbpf loads
+# it successfully
+$(OUTPUT)/test_xdp.o: test_xdp.c
+ $(CLANG) $(CLANG_FLAGS) \
+ -O2 -emit-llvm -c $< -o - | \
+ $(LLC) -march=bpf -mcpu=$(CPU) $(LLC_FLAGS) -filetype=obj -o $@
+ifeq ($(DWARF2BTF),y)
+ $(BTF_PAHOLE) -J $@
+endif
+
$(OUTPUT)/%.o: %.c
$(CLANG) $(CLANG_FLAGS) \
-O2 -target bpf -emit-llvm -c $< -o - | \
diff --git a/tools/testing/selftests/bpf/test_libbpf.sh b/tools/testing/selftests/bpf/test_libbpf.sh
index 156d89f1edcc..b45962a44243 100755
--- a/tools/testing/selftests/bpf/test_libbpf.sh
+++ b/tools/testing/selftests/bpf/test_libbpf.sh
@@ -33,17 +33,13 @@ trap exit_handler 0 2 3 6 9
libbpf_open_file test_l4lb.o
-# TODO: fix libbpf to load noinline functions
-# [warning] libbpf: incorrect bpf_call opcode
-#libbpf_open_file test_l4lb_noinline.o
+# Load a program with BPF-to-BPF calls
+libbpf_open_file test_l4lb_noinline.o
-# TODO: fix test_xdp_meta.c to load with libbpf
-# [warning] libbpf: test_xdp_meta.o doesn't provide kernel version
-#libbpf_open_file test_xdp_meta.o
+libbpf_open_file test_xdp_meta.o
-# TODO: fix libbpf to handle .eh_frame
-# [warning] libbpf: relocation failed: no section(10)
-#libbpf_open_file ../../../../samples/bpf/tracex3_kern.o
+# Load a program compiled without the "-target bpf" flag
+libbpf_open_file test_xdp.o
# Success
exit 0
diff --git a/tools/testing/selftests/bpf/test_xdp_meta.c b/tools/testing/selftests/bpf/test_xdp_meta.c
index 8d0182650653..2f42de66e2bb 100644
--- a/tools/testing/selftests/bpf/test_xdp_meta.c
+++ b/tools/testing/selftests/bpf/test_xdp_meta.c
@@ -8,6 +8,8 @@
#define round_up(x, y) ((((x) - 1) | __round_mask(x, y)) + 1)
#define ctx_ptr(ctx, mem) (void *)(unsigned long)ctx->mem
+int _version SEC("version") = 1;
+
SEC("t")
int ing_cls(struct __sk_buff *ctx)
{
--
2.7.4
^ permalink raw reply related
* [PATCH V1 net-next] net: ena: fix compilation error in xtensa architecture
From: akiyano @ 2018-10-21 15:07 UTC (permalink / raw)
To: davem, netdev
Cc: Arthur Kiyanovski, dwmw, zorik, matua, saeedb, msw, aliguori,
nafea, gtzalik, netanel, alisaidi
From: Arthur Kiyanovski <akiyano@amazon.com>
linux/prefetch.h is never explicitly included in ena_com, although
functions from it, such as prefetchw(), are used throughout ena_com.
This is an inclusion bug, and we fix it here by explicitly including
linux/prefetch.h. The bug was exposed when the driver was compiled
for the xtensa architecture.
Fixes: 689b2bdaaa14 ("net: ena: add functions for handling Low Latency Queues in ena_com")
Fixes: 8c590f977638 ("ena: Fix Kconfig dependency on X86")
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_com.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h b/drivers/net/ethernet/amazon/ena/ena_com.h
index ae8b485..078d6f2 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.h
+++ b/drivers/net/ethernet/amazon/ena/ena_com.h
@@ -38,6 +38,7 @@
#include <linux/dma-mapping.h>
#include <linux/gfp.h>
#include <linux/io.h>
+#include <linux/prefetch.h>
#include <linux/sched.h>
#include <linux/sizes.h>
#include <linux/spinlock.h>
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/9] net: dsa: bcm_sf2: simplify getting .driver_data
From: Andrew Lunn @ 2018-10-21 23:16 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-kernel, linux-renesas-soc, Vivien Didelot, Florian Fainelli,
David S. Miller, netdev
In-Reply-To: <20181021200021.1693-2-wsa+renesas@sang-engineering.com>
On Sun, Oct 21, 2018 at 10:00:12PM +0200, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-10-21 13:34 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet
Cc: Stephen Hemminger, netdev, rossi.f, Dimitris Michailidis
In-Reply-To: <cd6f5d1f-bd89-5da2-96be-85c2311ca0a1@gmail.com>
On 20.10.2018 00:25, Eric Dumazet wrote:
> On 10/19/2018 02:58 PM, Eric Dumazet wrote:
>> On 10/16/2018 06:00 AM, Eric Dumazet wrote:
>>> On Mon, Oct 15, 2018 at 11:30 PM Andre Tomt <andre@tomt.net> wrote:
>>>> I've seen similar on several systems with mlx4 cards when using 4.18.x -
>>>> that is hw csum failure followed by some backtrace.
>>>>
>>>> Only seems to happen on systems dealing with quite a bit of UDP.
>>>>
>>>
>>> Strange, because mlx4 on IPv6+UDP should not use CHECKSUM_COMPLETE,
>>> but CHECKSUM_UNNECESSARY
>>>
>>> I would be nice to track this a bit further, maybe by providing the
>>> full packet content.
>>>
<snip>
>>
>> As a matter of fact Dimitris found the issue in the patch and is working on a fix involving csum_block_sub()
>>
>> Problems comes from trimming an odd number of bytes.
>
> More exactly, trimming bytes starting at an odd offset.
No hw csum failures here since I deployed Dimitris fix on top of 4.18.16
32 hours ago.
Thanks
^ permalink raw reply
* [PATCH 1/1] net: dsa: legacy: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller, netdev
In-Reply-To: <20181021200105.2414-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
net/dsa/legacy.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/dsa/legacy.c b/net/dsa/legacy.c
index 8aa92b09db76..cb42939db776 100644
--- a/net/dsa/legacy.c
+++ b/net/dsa/legacy.c
@@ -686,8 +686,7 @@ static void dsa_shutdown(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int dsa_suspend(struct device *d)
{
- struct platform_device *pdev = to_platform_device(d);
- struct dsa_switch_tree *dst = platform_get_drvdata(pdev);
+ struct dsa_switch_tree *dst = dev_get_drvdata(d);
int i, ret = 0;
for (i = 0; i < dst->pd->nr_chips; i++) {
@@ -702,8 +701,7 @@ static int dsa_suspend(struct device *d)
static int dsa_resume(struct device *d)
{
- struct platform_device *pdev = to_platform_device(d);
- struct dsa_switch_tree *dst = platform_get_drvdata(pdev);
+ struct dsa_switch_tree *dst = dev_get_drvdata(d);
int i, ret = 0;
for (i = 0; i < dst->pd->nr_chips; i++) {
--
2.19.0
^ permalink raw reply related
* [PATCH 0/1] net: dsa: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:01 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-renesas-soc, Wolfram Sang, netdev
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
A branch, tested by buildbot, can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata
I have been asked if it couldn't be done for dev_set_drvdata as well. I checked
it and did not find one occasion where it could be simplified like this. Not
much of a surprise because driver_data is usually set in probe() functions
which access struct platform_device in many other ways.
I am open for other comments, suggestions, too, of course.
Here is the cocci-script I created:
@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
- struct platform_device *pdev = to_platform_device(d);
|
- struct platform_device *pdev;
...
- pdev = to_platform_device(d);
)
<... when != pdev
- &pdev->dev
+ d
...>
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- &pdev->dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (1):
net: dsa: legacy: simplify getting .driver_data
net/dsa/legacy.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--
2.19.0
^ permalink raw reply
* [PATCH] net/mlx5: Allocate enough space for the FDB sub-namespaces
From: Or Gerlitz @ 2018-10-21 11:05 UTC (permalink / raw)
To: David S. Miller; +Cc: Saeed Mahameed, netdev, Dan Carpenter
From: Dan Carpenter <dan.carpenter@oracle.com>
FDB_MAX_CHAIN is three. We wanted to allocate enough memory to hold four
structs but there are missing parentheses so we only allocate enough
memory for three structs and the first byte of the fourth one.
Fixes: 328edb499f99 ("net/mlx5: Split FDB fast path prio to multiple namespaces")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index 67ba4c9..9d73eb9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -2470,7 +2470,7 @@ static int init_fdb_root_ns(struct mlx5_flow_steering *steering)
return -ENOMEM;
steering->fdb_sub_ns = kzalloc(sizeof(steering->fdb_sub_ns) *
- FDB_MAX_CHAIN + 1, GFP_KERNEL);
+ (FDB_MAX_CHAIN + 1), GFP_KERNEL);
if (!steering->fdb_sub_ns)
return -ENOMEM;
--
2.3.7
^ permalink raw reply related
* [PATCH 1/1] ptp: ptp_dte: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-renesas-soc, Wolfram Sang, Richard Cochran, netdev
In-Reply-To: <20181021200039.1933-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/ptp/ptp_dte.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/ptp/ptp_dte.c b/drivers/ptp/ptp_dte.c
index a7dc43368df4..5b6393e3ea27 100644
--- a/drivers/ptp/ptp_dte.c
+++ b/drivers/ptp/ptp_dte.c
@@ -288,8 +288,7 @@ static int ptp_dte_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int ptp_dte_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct ptp_dte *ptp_dte = platform_get_drvdata(pdev);
+ struct ptp_dte *ptp_dte = dev_get_drvdata(dev);
u8 i;
for (i = 0; i < DTE_NUM_REGS_TO_RESTORE; i++) {
@@ -305,8 +304,7 @@ static int ptp_dte_suspend(struct device *dev)
static int ptp_dte_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct ptp_dte *ptp_dte = platform_get_drvdata(pdev);
+ struct ptp_dte *ptp_dte = dev_get_drvdata(dev);
u8 i;
for (i = 0; i < DTE_NUM_REGS_TO_RESTORE; i++) {
--
2.19.0
^ permalink raw reply related
* [PATCH 0/1] ptp: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-renesas-soc, Wolfram Sang, netdev
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
A branch, tested by buildbot, can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata
I have been asked if it couldn't be done for dev_set_drvdata as well. I checked
it and did not find one occasion where it could be simplified like this. Not
much of a surprise because driver_data is usually set in probe() functions
which access struct platform_device in many other ways.
I am open for other comments, suggestions, too, of course.
Here is the cocci-script I created:
@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
- struct platform_device *pdev = to_platform_device(d);
|
- struct platform_device *pdev;
...
- pdev = to_platform_device(d);
)
<... when != pdev
- &pdev->dev
+ d
...>
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- &pdev->dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (1):
ptp: ptp_dte: simplify getting .driver_data
drivers/ptp/ptp_dte.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--
2.19.0
^ permalink raw reply
* [PATCH 9/9] net: phy: mdio-mux-bcm-iproc: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, Andrew Lunn, Florian Fainelli,
David S. Miller, Ray Jui, Scott Branden, Jon Mason,
bcm-kernel-feedback-list, netdev, linux-arm-kernel
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/phy/mdio-mux-bcm-iproc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
index c017486e9b86..696bdf1e4576 100644
--- a/drivers/net/phy/mdio-mux-bcm-iproc.c
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -289,8 +289,7 @@ static int mdio_mux_iproc_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int mdio_mux_iproc_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct iproc_mdiomux_desc *md = platform_get_drvdata(pdev);
+ struct iproc_mdiomux_desc *md = dev_get_drvdata(dev);
clk_disable_unprepare(md->core_clk);
@@ -299,8 +298,7 @@ static int mdio_mux_iproc_suspend(struct device *dev)
static int mdio_mux_iproc_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct iproc_mdiomux_desc *md = platform_get_drvdata(pdev);
+ struct iproc_mdiomux_desc *md = dev_get_drvdata(dev);
clk_prepare_enable(md->core_clk);
mdio_mux_iproc_config(md);
--
2.19.0
^ permalink raw reply related
* [PATCH 8/9] net: ethernet: wiznet: w5300: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-renesas-soc, Wolfram Sang, David S. Miller, netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/ethernet/wiznet/w5300.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/wiznet/w5300.c b/drivers/net/ethernet/wiznet/w5300.c
index 80fdbff67d82..f9da5d6172e3 100644
--- a/drivers/net/ethernet/wiznet/w5300.c
+++ b/drivers/net/ethernet/wiznet/w5300.c
@@ -661,8 +661,7 @@ static int w5300_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int w5300_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct w5300_priv *priv = netdev_priv(ndev);
if (netif_running(ndev)) {
@@ -676,8 +675,7 @@ static int w5300_suspend(struct device *dev)
static int w5300_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct w5300_priv *priv = netdev_priv(ndev);
if (!netif_running(ndev)) {
--
2.19.0
^ permalink raw reply related
* [PATCH 7/9] net: ethernet: ti: davinci_emac: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, Grygorii Strashko,
David S. Miller, linux-omap, netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/ethernet/ti/davinci_emac.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index f270beebb428..9153db120352 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -2002,8 +2002,7 @@ static int davinci_emac_remove(struct platform_device *pdev)
static int davinci_emac_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
if (netif_running(ndev))
emac_dev_stop(ndev);
@@ -2013,8 +2012,7 @@ static int davinci_emac_suspend(struct device *dev)
static int davinci_emac_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
if (netif_running(ndev))
emac_dev_open(ndev);
--
2.19.0
^ permalink raw reply related
* [PATCH 6/9] net: ethernet: ti: cpsw: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, Grygorii Strashko,
David S. Miller, linux-omap, netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/ethernet/ti/cpsw.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 16dcbf36f8cc..4753ae7178fb 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -3658,8 +3658,7 @@ static int cpsw_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int cpsw_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
if (cpsw->data.dual_emac) {
@@ -3682,8 +3681,7 @@ static int cpsw_suspend(struct device *dev)
static int cpsw_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
/* Select default pin state */
--
2.19.0
^ permalink raw reply related
* [PATCH 5/9] net: ethernet: smsc: smc91x: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, Nicolas Pitre, David S. Miller,
netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/ethernet/smsc/smc91x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 8d6cff8bd162..4823b6a51134 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2447,8 +2447,7 @@ static int smc_drv_remove(struct platform_device *pdev)
static int smc_drv_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
if (ndev) {
if (netif_running(ndev)) {
--
2.19.0
^ permalink raw reply related
* [PATCH 4/9] net: ethernet: davicom: dm9000: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-renesas-soc, Wolfram Sang, David S. Miller, netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/ethernet/davicom/dm9000.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index 50222b7b81f3..0a82fcf16d35 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1722,8 +1722,7 @@ dm9000_probe(struct platform_device *pdev)
static int
dm9000_drv_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct board_info *db;
if (ndev) {
@@ -1745,8 +1744,7 @@ dm9000_drv_suspend(struct device *dev)
static int
dm9000_drv_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct board_info *db = netdev_priv(ndev);
if (ndev) {
--
2.19.0
^ permalink raw reply related
* [PATCH 3/9] net: ethernet: cadence: macb_main: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, Nicolas Ferre, David S. Miller,
netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/ethernet/cadence/macb_main.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 0acaef3ef548..8f5bf9166c11 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4156,8 +4156,7 @@ static int macb_remove(struct platform_device *pdev)
static int __maybe_unused macb_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *netdev = platform_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct macb *bp = netdev_priv(netdev);
netif_carrier_off(netdev);
@@ -4179,8 +4178,7 @@ static int __maybe_unused macb_suspend(struct device *dev)
static int __maybe_unused macb_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct net_device *netdev = platform_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev);
struct macb *bp = netdev_priv(netdev);
if (bp->wol & MACB_WOL_ENABLED) {
--
2.19.0
^ permalink raw reply related
* [PATCH 1/9] net: dsa: bcm_sf2: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller, netdev
In-Reply-To: <20181021200021.1693-1-wsa+renesas@sang-engineering.com>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Build tested only. buildbot is happy.
drivers/net/dsa/bcm_sf2.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 3017ecf82ca5..2eb68769562c 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1190,16 +1190,14 @@ static void bcm_sf2_sw_shutdown(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int bcm_sf2_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct bcm_sf2_priv *priv = platform_get_drvdata(pdev);
+ struct bcm_sf2_priv *priv = dev_get_drvdata(dev);
return dsa_switch_suspend(priv->dev->ds);
}
static int bcm_sf2_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct bcm_sf2_priv *priv = platform_get_drvdata(pdev);
+ struct bcm_sf2_priv *priv = dev_get_drvdata(dev);
return dsa_switch_resume(priv->dev->ds);
}
--
2.19.0
^ permalink raw reply related
* [PATCH 0/9] net: simplify getting .driver_data
From: Wolfram Sang @ 2018-10-21 20:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, Wolfram Sang, linux-omap, linux-arm-kernel,
netdev
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
A branch, tested by buildbot, can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata
I have been asked if it couldn't be done for dev_set_drvdata as well. I checked
it and did not find one occasion where it could be simplified like this. Not
much of a surprise because driver_data is usually set in probe() functions
which access struct platform_device in many other ways.
I am open for other comments, suggestions, too, of course.
Here is the cocci-script I created:
@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
- struct platform_device *pdev = to_platform_device(d);
|
- struct platform_device *pdev;
...
- pdev = to_platform_device(d);
)
<... when != pdev
- &pdev->dev
+ d
...>
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- &pdev->dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (9):
net: dsa: bcm_sf2: simplify getting .driver_data
net: dsa: qca8k: simplify getting .driver_data
net: ethernet: cadence: macb_main: simplify getting .driver_data
net: ethernet: davicom: dm9000: simplify getting .driver_data
net: ethernet: smsc: smc91x: simplify getting .driver_data
net: ethernet: ti: cpsw: simplify getting .driver_data
net: ethernet: ti: davinci_emac: simplify getting .driver_data
net: ethernet: wiznet: w5300: simplify getting .driver_data
net: phy: mdio-mux-bcm-iproc: simplify getting .driver_data
drivers/net/dsa/bcm_sf2.c | 6 ++----
drivers/net/dsa/qca8k.c | 6 ++----
drivers/net/ethernet/cadence/macb_main.c | 6 ++----
drivers/net/ethernet/davicom/dm9000.c | 6 ++----
drivers/net/ethernet/smsc/smc91x.c | 3 +--
drivers/net/ethernet/ti/cpsw.c | 6 ++----
drivers/net/ethernet/ti/davinci_emac.c | 6 ++----
drivers/net/ethernet/wiznet/w5300.c | 6 ++----
drivers/net/phy/mdio-mux-bcm-iproc.c | 6 ++----
9 files changed, 17 insertions(+), 34 deletions(-)
--
2.19.0
^ permalink raw reply
* Re: [PATCH] net/mlx5: allocate enough space in
From: Or Gerlitz @ 2018-10-21 10:56 UTC (permalink / raw)
To: Dan Carpenter
Cc: Saeed Mahameed, Paul Blakey, kernel-janitors, Linux Netdev List,
Leon Romanovsky
In-Reply-To: <CAJ3xEMhwcYYDWWLropG95T6TyE62OfJS+oPAFDZKLOVJSurNRQ@mail.gmail.com>
On Sat, Oct 20, 2018 at 11:37 PM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Fri, Oct 19, 2018 at 11:08 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > FDB_MAX_CHAIN is 3. We wanted to allocate enough memory to hold four
> > structs but there are missing parentheses so we only allocate enough
> > memory for three structs and the first byte of the fourth one.
>
> yeah, seems that we were wrong here and the fix is correct, at some
> point I saw Kasan screams but it was gone later, let me look, thanks for pointing it out.
OK, here's the kasan note:
[ 289.005141] BUG: KASAN: slab-out-of-bounds in
mlx5_init_fs+0x6a7/0x1176 [mlx5_core]
[ 289.005244] Write of size 8 at addr ffff8806cfb70e58 by task modprobe/6186
my .config was like this w.r.t kasan:
CONFIG_KASAN_SHADOW_OFFSET=0xdffffc0000000000
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_KASAN=y
# CONFIG_KASAN_EXTRA is not set
CONFIG_KASAN_OUTLINE=y
# CONFIG_KASAN_INLINE is not set
# CONFIG_TEST_KASAN is not set
where now, when I changed it to be:
CONFIG_KASAN_SHADOW_OFFSET=0xdffffc0000000000
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_KASAN=y
CONFIG_KASAN_EXTRA=y
# CONFIG_KASAN_OUTLINE is not set
CONFIG_KASAN_INLINE=y
# CONFIG_TEST_KASAN is not set
Kasan is there to spot the bug.
I will re-post your patch, this time to netdev since the original
commit is there
and so should be the fix, thanks for reporting/fixing!
Or.
^ permalink raw reply
* I NEED YOUR HELP URGENTLY!!!
From: GEN KELVIN @ 2018-10-21 0:26 UTC (permalink / raw)
To: Recipients
Compliment of the day to you. I am Gen.Kelvin W Howard, I am sending this brief letter to solicit your partnership of Sixteen Million Two Hundred Thousand United States Dollars ($16,200,000). I shall send you more information and procedures when I receive positive response from you.Best Regards,
CONTACT ME: kivenhoward@gmail.com
Gen.Kelvin W Howard
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH net-next] octeontx2-af: Remove set but not used variable 'block'
From: YueHaibing @ 2018-10-21 10:07 UTC (permalink / raw)
To: Sunil Kovvuri
Cc: Sunil Goutham, Linu Cherian, Geetha sowjanya, jerinj,
David S. Miller, Linux Netdev List, kernel-janitors
In-Reply-To: <CA+sq2CekhmaVQddoy2T0e5B9KwG2=_8d+KVFavqfnJfAFSPs2A@mail.gmail.com>
On 2018/10/19 21:36, Sunil Kovvuri wrote:
> On Fri, Oct 19, 2018 at 6:11 PM YueHaibing <yuehaibing@huawei.com> wrote:
>>
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c: In function 'rvu_npa_init':
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c:446:20: warning:
>> variable 'block' set but not used [-Wunused-but-set-variable]
>>
>> It never used since introduction in
>> commit 7a37245ef23f ("octeontx2-af: NPA block admin queue init")
>>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c
>> index 0e43a69..7531fdc 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c
>> @@ -443,15 +443,12 @@ static int npa_aq_init(struct rvu *rvu, struct rvu_block *block)
>> int rvu_npa_init(struct rvu *rvu)
>> {
>> struct rvu_hwinfo *hw = rvu->hw;
>> - struct rvu_block *block;
>> int blkaddr, err;
>>
>> blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NPA, 0);
>> if (blkaddr < 0)
>> return 0;
>>
>> - block = &hw->block[blkaddr];
>> -
>> /* Initialize admin queue */
>> err = npa_aq_init(rvu, &hw->block[blkaddr]);
>> if (err)
>>
>
> Thanks for the patch.
> Which GCC version do you use ?
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
> Before submitting patches I did test compiling specifically with these
> "make arch=X86 -j8 -Werror=unused-function -Wunused-but-set-variable"
> but that didn't throw these warnings.
>
> Thanks,
> Sunil.
>
> .
>
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: enable (uncomment) all tests in test_libbpf.sh
From: Jesper Dangaard Brouer @ 2018-10-21 9:57 UTC (permalink / raw)
To: Quentin Monnet
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, oss-drivers, brouer
In-Reply-To: <1540072824-27914-1-git-send-email-quentin.monnet@netronome.com>
On Sat, 20 Oct 2018 23:00:24 +0100
Quentin Monnet <quentin.monnet@netronome.com> wrote:
> libbpf is now able to load successfully test_l4lb_noinline.o and
> samples/bpf/tracex3_kern.o, so we can uncomment related tests from
> test_libbpf.c and remove the associated "TODO"s.
Thanks for working on this, comments below.
> It is also trivial to fix test_xdp_noinline.o so that it provides a
> version and can be loaded. Fix it and uncomment this test as well.
>
> For the record, the error message obtainted with tracex3_kern.o was
> fixed by commit e3d91b0ca523 ("tools/libbpf: handle issues with bpf ELF
> objects containing .eh_frames")
>
> I have not been abled to reproduce the "libbpf: incorrect bpf_call
> opcode" error for test_l4lb_noinline.o, even with the version of libbpf
> present at the time when test_libbpf.sh and test_libbpf_open.c were
> created.
>
> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> ---
> tools/testing/selftests/bpf/test_libbpf.sh | 12 +++---------
> tools/testing/selftests/bpf/test_xdp_meta.c | 2 ++
> 2 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/test_libbpf.sh b/tools/testing/selftests/bpf/test_libbpf.sh
> index 156d89f1edcc..a426f28163a5 100755
> --- a/tools/testing/selftests/bpf/test_libbpf.sh
> +++ b/tools/testing/selftests/bpf/test_libbpf.sh
> @@ -33,17 +33,11 @@ trap exit_handler 0 2 3 6 9
>
> libbpf_open_file test_l4lb.o
>
> -# TODO: fix libbpf to load noinline functions
> -# [warning] libbpf: incorrect bpf_call opcode
> -#libbpf_open_file test_l4lb_noinline.o
> +libbpf_open_file test_l4lb_noinline.o
>
> -# TODO: fix test_xdp_meta.c to load with libbpf
> -# [warning] libbpf: test_xdp_meta.o doesn't provide kernel version
> -#libbpf_open_file test_xdp_meta.o
> +libbpf_open_file test_xdp_meta.o
>
> -# TODO: fix libbpf to handle .eh_frame
> -# [warning] libbpf: relocation failed: no section(10)
> -#libbpf_open_file ../../../../samples/bpf/tracex3_kern.o
> +libbpf_open_file ../../../../samples/bpf/tracex3_kern.o
I don't like the ../../../../samples/bpf/ reference (even-through I
added this TODO), as the kselftests AFAIK support installing the
selftests and then this tests will fail.
Maybe we can find another example kern.o file?
(which isn't compiled with -target bpf)
> # Success
> exit 0
> diff --git a/tools/testing/selftests/bpf/test_xdp_meta.c b/tools/testing/selftests/bpf/test_xdp_meta.c
> index 8d0182650653..2f42de66e2bb 100644
> --- a/tools/testing/selftests/bpf/test_xdp_meta.c
> +++ b/tools/testing/selftests/bpf/test_xdp_meta.c
> @@ -8,6 +8,8 @@
> #define round_up(x, y) ((((x) - 1) | __round_mask(x, y)) + 1)
> #define ctx_ptr(ctx, mem) (void *)(unsigned long)ctx->mem
>
> +int _version SEC("version") = 1;
> +
> SEC("t")
> int ing_cls(struct __sk_buff *ctx)
> {
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ 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