* [PATCH 1/5] net: hns3: remove unnecessary devm_kfree
From: Barry Song @ 2020-06-18 1:02 UTC (permalink / raw)
To: davem, kuba
Cc: yisen.zhuang, salil.mehta, netdev, linyunsheng, linux-kernel,
linuxarm, Barry Song
In-Reply-To: <20200618010211.75840-1-song.bao.hua@hisilicon.com>
since we are using device-managed function, it is unnecessary
to free in probe.
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index b14f2abc2425..1817d7f2e5f6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2097,10 +2097,8 @@ static int hns3_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, ae_dev);
ret = hnae3_register_ae_dev(ae_dev);
- if (ret) {
- devm_kfree(&pdev->dev, ae_dev);
+ if (ret)
pci_set_drvdata(pdev, NULL);
- }
return ret;
}
@@ -2157,7 +2155,6 @@ static void hns3_shutdown(struct pci_dev *pdev)
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(pdev);
hnae3_unregister_ae_dev(ae_dev);
- devm_kfree(&pdev->dev, ae_dev);
pci_set_drvdata(pdev, NULL);
if (system_state == SYSTEM_POWER_OFF)
--
2.23.0
^ permalink raw reply related
* [PATCH 0/5] net: hns3: a bundle of minor cleanup and fixes
From: Barry Song @ 2020-06-18 1:02 UTC (permalink / raw)
To: davem, kuba
Cc: yisen.zhuang, salil.mehta, netdev, linyunsheng, linux-kernel,
linuxarm, Barry Song
some minor changes to either improve the readability or make the code align
with linux APIs better.
Barry Song (5):
net: hns3: remove unnecessary devm_kfree
net: hns3: pointer type of buffer should be void
net: hns3: rename buffer-related functions
net: hns3: replace disable_irq by IRQ_NOAUTOEN flag
net: hns3: streaming dma buffer sync between cpu and device
.../net/ethernet/hisilicon/hns3/hns3_enet.c | 41 ++++++++++++-------
.../net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +-
2 files changed, 28 insertions(+), 15 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH] [net/sched]: Remove redundant condition in qdisc_graft
From: Gaurav Singh @ 2020-06-18 0:55 UTC (permalink / raw)
To: gaurav1086, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
David S. Miller, Jakub Kicinski, open list:TC subsystem,
open list
parent cannot be NULL here since its in the else part
of the if (parent == NULL) condition. Remove the extra
check on parent pointer.
Signed-off-by: Gaurav Singh <gaurav1086@gmail.com>
---
net/sched/sch_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 9a3449b56bd6..8c92d00c5c8e 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1094,7 +1094,7 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,
/* Only support running class lockless if parent is lockless */
if (new && (new->flags & TCQ_F_NOLOCK) &&
- parent && !(parent->flags & TCQ_F_NOLOCK))
+ && !(parent->flags & TCQ_F_NOLOCK))
qdisc_clear_nolock(new);
if (!cops || !cops->graft)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next 4/9] tools/bpftool: move map/prog parsing logic into common
From: Quentin Monnet @ 2020-06-18 0:30 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast, daniel
Cc: andrii.nakryiko, kernel-team, Hao Luo, Arnaldo Carvalho de Melo,
Song Liu
In-Reply-To: <20200617161832.1438371-5-andriin@fb.com>
2020-06-17 09:18 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Move functions that parse map and prog by id/tag/name/etc outside of
> map.c/prog.c, respectively. These functions are used outside of those files
> and are generic enough to be in common. This also makes heavy-weight map.c and
> prog.c more decoupled from the rest of bpftool files and facilitates more
> lightweight bootstrap bpftool variant.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
^ permalink raw reply
* Re: [PATCH bpf-next 5/9] tools/bpftool: minimize bootstrap bpftool
From: Quentin Monnet @ 2020-06-18 0:30 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast, daniel
Cc: andrii.nakryiko, kernel-team, Hao Luo, Arnaldo Carvalho de Melo,
Song Liu
In-Reply-To: <20200617161832.1438371-6-andriin@fb.com>
2020-06-17 09:18 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Build minimal "bootstrap mode" bpftool to enable skeleton (and, later,
> vmlinux.h generation), instead of building almost complete, but slightly
> different (w/o skeletons, etc) bpftool to bootstrap complete bpftool build.
>
> Current approach doesn't scale well (engineering-wise) when adding more BPF
> programs to bpftool and other complicated functionality, as it requires
> constant adjusting of the code to work in both bootstrapped mode and normal
> mode.
>
> So it's better to build only minimal bpftool version that supports only BPF
> skeleton code generation and BTF-to-C conversion. Thankfully, this is quite
> easy to accomplish due to internal modularity of bpftool commands. This will
> also allow to keep adding new functionality to bpftool in general, without the
> need to care about bootstrap mode for those new parts of bpftool.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
^ permalink raw reply
* Re: [PATCH bpf-next 6/9] tools/bpftool: generalize BPF skeleton support and generate vmlinux.h
From: Quentin Monnet @ 2020-06-18 0:30 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast, daniel
Cc: andrii.nakryiko, kernel-team, Hao Luo, Arnaldo Carvalho de Melo,
Song Liu
In-Reply-To: <20200617161832.1438371-7-andriin@fb.com>
2020-06-17 09:18 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Adapt Makefile to support BPF skeleton generation beyond single profiler.bpf.c
> case. Also add vmlinux.h generation and switch profiler.bpf.c to use it.
>
> clang-bpf-global-var feature is extended and renamed to clang-bpf-co-re to
> check for support of preserve_access_index attribute, which, together with BTF
> for global variables, is the minimum requirement for modern BPF programs.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
^ permalink raw reply
* Re: [PATCH bpf-next 9/9] tools/bpftool: add documentation and sample output for process info
From: Quentin Monnet @ 2020-06-18 0:25 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast, daniel
Cc: andrii.nakryiko, kernel-team, Hao Luo, Arnaldo Carvalho de Melo,
Song Liu
In-Reply-To: <20200617161832.1438371-10-andriin@fb.com>
2020-06-17 09:18 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Add statements about bpftool being able to discover process info, holding
> reference to BPF map, prog, link, or BTF. Show example output as well.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/bpf/bpftool/Documentation/bpftool-btf.rst | 5 +++++
> tools/bpf/bpftool/Documentation/bpftool-link.rst | 13 ++++++++++++-
> tools/bpf/bpftool/Documentation/bpftool-map.rst | 8 +++++++-
> tools/bpf/bpftool/Documentation/bpftool-prog.rst | 11 +++++++++++
> 4 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> index ce3a724f50c1..85f7c82ebb28 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> @@ -36,6 +36,11 @@ DESCRIPTION
> otherwise list all BTF objects currently loaded on the
> system.
>
> + Since Linux 5.8 bpftool is able to discover information about
> + processes that hold open file descriptors (FDs) against BPF
> + links. On such kernels bpftool will automatically emit this
Copy-paste error: s/BPF links/BTF objects/
> + information as well.
> +
> **bpftool btf dump** *BTF_SRC*
> Dump BTF entries from a given *BTF_SRC*.
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-link.rst b/tools/bpf/bpftool/Documentation/bpftool-link.rst
> index 0e43d7b06c11..1da7ef65b514 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-link.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-link.rst
> @@ -37,6 +37,11 @@ DESCRIPTION
> zero or more named attributes, some of which depend on type
> of link.
>
> + Since Linux 5.8 bpftool is able to discover information about
> + processes that hold open file descriptors (FDs) against BPF
> + links. On such kernels bpftool will automatically emit this
> + information as well.
> +
> **bpftool link pin** *LINK* *FILE*
> Pin link *LINK* as *FILE*.
>
> @@ -82,6 +87,7 @@ EXAMPLES
>
> 10: cgroup prog 25
> cgroup_id 614 attach_type egress
> + pids test_progs(2238417)
(That's a big PID. Maybe something below the default max pid (32768)
might be less confusing for users, but also maybe that's just me
nitpicking too much.)
>
> **# bpftool --json --pretty link show**
>
> @@ -91,7 +97,12 @@ EXAMPLES
> "type": "cgroup",
> "prog_id": 25,
> "cgroup_id": 614,
> - "attach_type": "egress"
> + "attach_type": "egress",
> + "pids": [{
> + "pid": 2238417,
> + "comm": "test_progs"
> + }
> + ]
> }
> ]
>
^ permalink raw reply
* Re: [PATCH bpf-next 8/9] tools/bpftool: show info for processes holding BPF map/prog/link/btf FDs
From: Quentin Monnet @ 2020-06-18 0:24 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast, daniel
Cc: andrii.nakryiko, kernel-team, Hao Luo, Arnaldo Carvalho de Melo,
Song Liu
In-Reply-To: <20200617161832.1438371-9-andriin@fb.com>
2020-06-17 09:18 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Add bpf_iter-based way to find all the processes that hold open FDs against
> BPF object (map, prog, link, btf). bpftool always attempts to discover this,
> but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
> Process name and PID are emitted for each process (task group).
>
> Sample output for each of 4 BPF objects:
>
> $ sudo ./bpftool prog show
> 2694: cgroup_device tag 8c42dee26e8cd4c2 gpl
> loaded_at 2020-06-16T15:34:32-0700 uid 0
> xlated 648B jited 409B memlock 4096B
> pids systemd(1)
> 2907: cgroup_skb name egress tag 9ad187367cf2b9e8 gpl
> loaded_at 2020-06-16T18:06:54-0700 uid 0
> xlated 48B jited 59B memlock 4096B map_ids 2436
> btf_id 1202
> pids test_progs(2238417), test_progs(2238445)
>
> $ sudo ./bpftool map show
> 2436: array name test_cgr.bss flags 0x400
> key 4B value 8B max_entries 1 memlock 8192B
> btf_id 1202
> pids test_progs(2238417), test_progs(2238445)
> 2445: array name pid_iter.rodata flags 0x480
> key 4B value 4B max_entries 1 memlock 8192B
> btf_id 1214 frozen
> pids bpftool(2239612)
>
> $ sudo ./bpftool link show
> 61: cgroup prog 2908
> cgroup_id 375301 attach_type egress
> pids test_progs(2238417), test_progs(2238445)
> 62: cgroup prog 2908
> cgroup_id 375344 attach_type egress
> pids test_progs(2238417), test_progs(2238445)
>
> $ sudo ./bpftool btf show
> 1202: size 1527B prog_ids 2908,2907 map_ids 2436
> pids test_progs(2238417), test_progs(2238445)
> 1242: size 34684B
> pids bpftool(2258892)
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
[...]
> diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c
> new file mode 100644
> index 000000000000..3474a91743ff
> --- /dev/null
> +++ b/tools/bpf/bpftool/pids.c
> @@ -0,0 +1,229 @@
[...]
> +int build_obj_refs_table(struct obj_refs_table *table, enum bpf_obj_type type)
> +{
> + char buf[4096];
> + struct pid_iter_bpf *skel;
> + struct pid_iter_entry *e;
> + int err, ret, fd = -1, i;
> + libbpf_print_fn_t default_print;
> +
> + hash_init(table->table);
> + set_max_rlimit();
> +
> + skel = pid_iter_bpf__open();
> + if (!skel) {
> + p_err("failed to open PID iterator skeleton");
> + return -1;
> + }
> +
> + skel->rodata->obj_type = type;
> +
> + /* we don't want output polluted with libbpf errors if bpf_iter is not
> + * supported
> + */
> + default_print = libbpf_set_print(libbpf_print_none);
> + err = pid_iter_bpf__load(skel);
> + libbpf_set_print(default_print);
> + if (err) {
> + /* too bad, kernel doesn't support BPF iterators yet */
> + err = 0;
> + goto out;
> + }
> + err = pid_iter_bpf__attach(skel);
> + if (err) {
> + /* if we loaded above successfully, attach has to succeed */
> + p_err("failed to attach PID iterator: %d", err);
Nit: What about using strerror(err) for the error messages, here and
below? It's easier to read than an integer value.
> + goto out;
> + }
> +
> + fd = bpf_iter_create(bpf_link__fd(skel->links.iter));
> + if (fd < 0) {
> + err = -errno;
> + p_err("failed to create PID iterator session: %d", err);
> + goto out;
> + }
> +
> + while (true) {
> + ret = read(fd, buf, sizeof(buf));
> + if (ret < 0) {
> + err = -errno;
> + p_err("failed to read PID iterator output: %d", err);
> + goto out;
> + }
> + if (ret == 0)
> + break;
> + if (ret % sizeof(*e)) {
> + err = -EINVAL;
> + p_err("invalid PID iterator output format");
> + goto out;
> + }
> + ret /= sizeof(*e);
> +
> + e = (void *)buf;
> + for (i = 0; i < ret; i++, e++) {
> + add_ref(table, e);
> + }
> + }
> + err = 0;
> +out:
> + if (fd >= 0)
> + close(fd);
> + pid_iter_bpf__destroy(skel);
> + return err;
> +}
[...]
> diff --git a/tools/bpf/bpftool/skeleton/pid_iter.bpf.c b/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
> new file mode 100644
> index 000000000000..f560e48add07
> --- /dev/null
> +++ b/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
> @@ -0,0 +1,80 @@
> +// SPDX-License-Identifier: GPL-2.0
This would make it the only file not dual-licensed GPL/BSD in bpftool.
We've had issues with that before [0], although linking to libbfd is no
more a hard requirement. But I see you used a dual-license in the
corresponding header file pid_iter.h, so is the single license
intentional here? Or would you consider GPL/BSD?
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896165#38
> +// Copyright (c) 2020 Facebook
> +#include <vmlinux.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_core_read.h>
> +#include <bpf/bpf_tracing.h>
> +#include "pid_iter.h"
[...]
> +
> +char LICENSE[] SEC("license") = "GPL";
> diff --git a/tools/bpf/bpftool/skeleton/pid_iter.h b/tools/bpf/bpftool/skeleton/pid_iter.h
> new file mode 100644
> index 000000000000..5692cf257adb
> --- /dev/null
> +++ b/tools/bpf/bpftool/skeleton/pid_iter.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
[...]
^ permalink raw reply
* Re: [PATCH net-next 1/5] net: tso: double TSO_HEADER_SIZE value
From: Eric Dumazet @ 2020-06-18 0:14 UTC (permalink / raw)
To: Jakub Kicinski, Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Willem de Bruijn,
Antoine Tenart
In-Reply-To: <20200617170229.04454d36@kicinski-fedora-PC1C0HJN>
On 6/17/20 5:02 PM, Jakub Kicinski wrote:
> On Wed, 17 Jun 2020 11:48:15 -0700 Eric Dumazet wrote:
>> Transport header size could be 60 bytes, and network header
>> size can also be 60 bytes. Add the Ethernet header and we
>> are above 128 bytes.
>>
>> Since drivers using net/core/tso.c usually allocates
>> one DMA coherent piece of memory per TX queue, this patch
>> might cause issues if a driver was using too many slots.
>>
>> For 1024 slots, we would need 256 KB of physically
>> contiguous memory instead of 128 KB.
>>
>> Alternative fix would be to add checks in the fast path,
>> but this involves more work in all drivers using net/core/tso.c.
>>
>> Fixes: f9cbe9a556af ("net: define the TSO header size in net/tso.h")
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Antoine Tenart <antoine.tenart@bootlin.com>
>
> Some warnings popping up in this series with W=1 C=1:
>
> drivers/net/ethernet/marvell/octeontx2/af/common.h:65:26: warning: cast truncates bits from constant value (100 becomes 0)
>
Nice, thanks I will take a look.
^ permalink raw reply
* Re: linux-next: build failures after merge of the vfs tree
From: Stephen Rothwell @ 2020-06-18 0:08 UTC (permalink / raw)
To: Herbert Xu
Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List,
netdev
In-Reply-To: <20200617073845.GA20077@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
Hi all,
On Wed, 17 Jun 2020 17:38:45 +1000 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Wed, Jun 17, 2020 at 05:31:02PM +1000, Stephen Rothwell wrote:
> > > >
> > > > Presumably another include needed:
> > > >
> > > > arch/s390/lib/test_unwind.c:49:2: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration]
> > > > arch/s390/lib/test_unwind.c:99:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
> >
> > And more (these are coming from other's builds):
> >
> > drivers/remoteproc/qcom_q6v5_mss.c:772:3: error: implicit declaration of function 'kfree' [-Werror,-Wimplicit-function-declaration]
> > drivers/remoteproc/qcom_q6v5_mss.c:808:2: error: implicit declaration of function 'kfree' [-Werror,-Wimplicit-function-declaration]
> > drivers/remoteproc/qcom_q6v5_mss.c:1195:2: error: implicit declaration of function 'kfree' [-Werror,-Wimplicit-function-declaration]
> >
> > They may have other causes as they are full linux-next builds (not just
> > after the merge of the vfs tree), but the timing is suspicious.
>
> OK, here's a patch for both of these together:
>
> diff --git a/arch/s390/lib/test_unwind.c b/arch/s390/lib/test_unwind.c
> index 32b7a30b2485..eb382ceaa116 100644
> --- a/arch/s390/lib/test_unwind.c
> +++ b/arch/s390/lib/test_unwind.c
> @@ -9,6 +9,7 @@
> #include <linux/kallsyms.h>
> #include <linux/kthread.h>
> #include <linux/module.h>
> +#include <linux/slab.h>
> #include <linux/string.h>
> #include <linux/kprobes.h>
> #include <linux/wait.h>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index feb70283b6a2..903b2bb97e12 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -26,6 +26,7 @@
> #include <linux/reset.h>
> #include <linux/soc/qcom/mdt_loader.h>
> #include <linux/iopoll.h>
> +#include <linux/slab.h>
>
> #include "remoteproc_internal.h"
> #include "qcom_common.h"
I have applied those 2 by hand for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH bpf-next v4 3/3] bpf: add SO_KEEPALIVE and related options to bpf_setsockopt
From: John Fastabend @ 2020-06-18 0:03 UTC (permalink / raw)
To: Dmitry Yakunin, daniel, alexei.starovoitov
Cc: davem, brakmo, eric.dumazet, kafai, bpf, netdev
In-Reply-To: <20200617110217.35669-3-zeil@yandex-team.ru>
Dmitry Yakunin wrote:
> This patch adds support of SO_KEEPALIVE flag and TCP related options
> to bpf_setsockopt() routine. This is helpful if we want to enable or tune
> TCP keepalive for applications which don't do it in the userspace code.
>
> v2:
> - update kernel-doc (Nikita Vetoshkin <nekto0n@yandex-team.ru>)
>
> Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next 4/5] net: tso: cache transport header length
From: Jakub Kicinski @ 2020-06-18 0:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Willem de Bruijn,
Antoine Tenart
In-Reply-To: <20200617184819.49986-5-edumazet@google.com>
On Wed, 17 Jun 2020 11:48:18 -0700 Eric Dumazet wrote:
> Add tlen field into struct tso_t, and change tso_start()
> to return skb_transport_offset(skb) + tso->tlen
>
> This removes from callers the need to use tcp_hdrlen(skb) and
> will ease UDP segmentation offload addition.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c: In function otx2_sq_append_tso:
drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c:631:6: warning: hdr_len is used uninitialized in this function [-Wuninitialized]
631 | if (otx2_dma_map_tso_skb(pfvf, sq, skb, first_sqe, hdr_len)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH net-next 1/5] net: tso: double TSO_HEADER_SIZE value
From: Jakub Kicinski @ 2020-06-18 0:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Willem de Bruijn,
Antoine Tenart
In-Reply-To: <20200617184819.49986-2-edumazet@google.com>
On Wed, 17 Jun 2020 11:48:15 -0700 Eric Dumazet wrote:
> Transport header size could be 60 bytes, and network header
> size can also be 60 bytes. Add the Ethernet header and we
> are above 128 bytes.
>
> Since drivers using net/core/tso.c usually allocates
> one DMA coherent piece of memory per TX queue, this patch
> might cause issues if a driver was using too many slots.
>
> For 1024 slots, we would need 256 KB of physically
> contiguous memory instead of 128 KB.
>
> Alternative fix would be to add checks in the fast path,
> but this involves more work in all drivers using net/core/tso.c.
>
> Fixes: f9cbe9a556af ("net: define the TSO header size in net/tso.h")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>
Some warnings popping up in this series with W=1 C=1:
drivers/net/ethernet/marvell/octeontx2/af/common.h:65:26: warning: cast truncates bits from constant value (100 becomes 0)
^ permalink raw reply
* Re: [PATCH net-next v7 6/6] net: phy: DP83822: Add ability to advertise Fiber connection
From: Jakub Kicinski @ 2020-06-18 0:00 UTC (permalink / raw)
To: Dan Murphy
Cc: andrew, f.fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200617182019.6790-7-dmurphy@ti.com>
On Wed, 17 Jun 2020 13:20:19 -0500 Dan Murphy wrote:
> +static int dp83822_config_init(struct phy_device *phydev)
> +{
> + struct dp83822_private *dp83822 = phydev->priv;
> + int rgmii_delay;
> + int err = 0;
> +
> + if (phy_interface_is_rgmii(phydev)) {
> + if (dp83822->rx_int_delay)
> + rgmii_delay = DP83822_RX_CLK_SHIFT;
> +
> + if (dp83822->tx_int_delay)
> + rgmii_delay |= DP83822_TX_CLK_SHIFT;
> +
> + if (rgmii_delay)
> + err = phy_set_bits_mmd(phydev, DP83822_DEVADDR,
> + MII_DP83822_RCSR, rgmii_delay);
> + }
> +
> + return dp8382x_disable_wol(phydev);
> +}
drivers/net/phy/dp83822.c: In function dp83822_config_init:
drivers/net/phy/dp83822.c:282:6: warning: variable err set but not used [-Wunused-but-set-variable]
282 | int err = 0;
| ^~~
^ permalink raw reply
* RE: [PATCH bpf-next v4 1/3] sock: move sock_valbool_flag to header
From: John Fastabend @ 2020-06-18 0:00 UTC (permalink / raw)
To: Dmitry Yakunin, daniel, alexei.starovoitov
Cc: davem, brakmo, eric.dumazet, kafai, bpf, netdev
In-Reply-To: <20200617110217.35669-1-zeil@yandex-team.ru>
Dmitry Yakunin wrote:
> This is preparation for usage in bpf_setsockopt.
>
> Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* RE: [PATCH bpf-next v4 1/3] sock: move sock_valbool_flag to header
From: John Fastabend @ 2020-06-17 23:54 UTC (permalink / raw)
To: Dmitry Yakunin, daniel, alexei.starovoitov
Cc: davem, brakmo, eric.dumazet, kafai, bpf, netdev
In-Reply-To: <20200617110217.35669-1-zeil@yandex-team.ru>
Dmitry Yakunin wrote:
> This is preparation for usage in bpf_setsockopt.
>
> Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* RE: [PATCH] bpf: Allow small structs to be type of function argument
From: John Fastabend @ 2020-06-17 23:20 UTC (permalink / raw)
To: Jiri Olsa, Alexei Starovoitov, Daniel Borkmann
Cc: netdev, bpf, Yonghong Song, Martin KaFai Lau, Jakub Kicinski,
David Miller, John Fastabend, Jesper Dangaard Brouer,
Andrii Nakryiko, KP Singh, Masanori Misono
In-Reply-To: <20200616173556.2204073-1-jolsa@kernel.org>
Jiri Olsa wrote:
> This way we can have trampoline on function
> that has arguments with types like:
>
> kuid_t uid
> kgid_t gid
>
> which unwind into small structs like:
>
> typedef struct {
> uid_t val;
> } kuid_t;
>
> typedef struct {
> gid_t val;
> } kgid_t;
>
> And we can use them in bpftrace like:
> (assuming d_path changes are in)
>
> # bpftrace -e 'lsm:path_chown { printf("uid %d, gid %d\n", args->uid, args->gid) }'
> Attaching 1 probe...
> uid 0, gid 0
> uid 1000, gid 1000
> ...
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> kernel/bpf/btf.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 58c9af1d4808..f8fee5833684 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -362,6 +362,14 @@ static bool btf_type_is_struct(const struct btf_type *t)
> return kind == BTF_KIND_STRUCT || kind == BTF_KIND_UNION;
> }
>
> +/* type is struct and its size is within 8 bytes
> + * and it can be value of function argument
> + */
> +static bool btf_type_is_struct_arg(const struct btf_type *t)
> +{
> + return btf_type_is_struct(t) && (t->size <= sizeof(u64));
Can you comment on why sizeof(u64) here? The int types can be larger
than 64 for example and don't have a similar check, maybe the should
as well?
Here is an example from some made up program I ran through clang and
bpftool.
[2] INT '__int128' size=16 bits_offset=0 nr_bits=128 encoding=SIGNED
We also have btf_type_int_is_regular to decide if the int is of some
"regular" size but I don't see it used in these paths.
> +}
> +
> static bool __btf_type_is_struct(const struct btf_type *t)
> {
> return BTF_INFO_KIND(t->info) == BTF_KIND_STRUCT;
> @@ -3768,7 +3776,7 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
> /* skip modifiers */
> while (btf_type_is_modifier(t))
> t = btf_type_by_id(btf, t->type);
> - if (btf_type_is_int(t) || btf_type_is_enum(t))
> + if (btf_type_is_int(t) || btf_type_is_enum(t) || btf_type_is_struct_arg(t))
> /* accessing a scalar */
> return true;
> if (!btf_type_is_ptr(t)) {
> @@ -4161,6 +4169,8 @@ static int __get_type_size(struct btf *btf, u32 btf_id,
> return sizeof(void *);
> if (btf_type_is_int(t) || btf_type_is_enum(t))
> return t->size;
> + if (btf_type_is_struct_arg(t))
> + return t->size;
> *bad_type = t;
> return -EINVAL;
> }
> --
> 2.25.4
>
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Joe Perches @ 2020-06-17 23:12 UTC (permalink / raw)
To: Denis Efremov, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
Matthew Wilcox, David Rientjes
Cc: Michal Hocko, Johannes Weiner, Dan Carpenter, David Sterba,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <17e4fede-bab0-d93c-6964-69decc889d7d@ispras.ru>
On Thu, 2020-06-18 at 00:31 +0300, Denis Efremov wrote:
>
> On 6/16/20 9:53 PM, Joe Perches wrote:
> > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > > v4:
> > > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > > so that it can be backported to stable.
> > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > > now as there can be a bit more discussion on what is best. It will be
> > > introduced as a separate patch later on after this one is merged.
> >
> > To this larger audience and last week without reply:
> > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/
> >
> > Are there _any_ fastpath uses of kfree or vfree?
> >
> > Many patches have been posted recently to fix mispairings
> > of specific types of alloc and free functions.
>
> I've prepared a coccinelle script to highlight these mispairings in a function
> a couple of days ago: https://lkml.org/lkml/2020/6/5/953
> I've listed all the fixes in the commit message.
>
> Not so many mispairings actually, and most of them are harmless like:
> kmalloc(E) -> kvfree(E)
>
> However, coccinelle script can't detect cross-functions mispairings, i.e.
> allocation in one function, free in another funtion.
Hey Denis, thanks for those patches.
If possible, it's probably better to not require these pairings
and use a single standard kfree/free function.
Given the existing ifs in kfree in slab/slob/slub, it seems
likely that adding a few more wouldn't have much impact.
^ permalink raw reply
* [PATCH][next] mISDN: hfcsusb: Use struct_size() helper
From: Gustavo A. R. Silva @ 2020-06-17 23:15 UTC (permalink / raw)
To: Karsten Keil, David S. Miller; +Cc: netdev, linux-kernel, Gustavo A. R. Silva
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 621364bb6b12..4274906f8654 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -261,8 +261,7 @@ hfcsusb_ph_info(struct hfcsusb *hw)
phi->bch[i].Flags = hw->bch[i].Flags;
}
_queue_data(&dch->dev.D, MPH_INFORMATION_IND, MISDN_ID_ANY,
- sizeof(struct ph_info_dch) + dch->dev.nrbchan *
- sizeof(struct ph_info_ch), phi, GFP_ATOMIC);
+ struct_size(phi, bch, dch->dev.nrbchan), phi, GFP_ATOMIC);
kfree(phi);
}
--
2.27.0
^ permalink raw reply related
* [PATCH] lan743x: allow mac address to come from dt
From: Tim Harvey @ 2020-06-17 22:59 UTC (permalink / raw)
To: Bryan Whitehead, Microchip Linux Driver Support, David S . Miller,
Jakub Kicinski
Cc: netdev, linux-kernel, Tim Harvey
If a valid mac address is present in dt, use that before using
CSR's or a random mac address.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
drivers/net/ethernet/microchip/lan743x_main.c | 41 ++++++++++++++++-----------
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index 7ef22bf..50ad56b 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -12,6 +12,7 @@
#include <linux/rtnetlink.h>
#include <linux/iopoll.h>
#include <linux/crc16.h>
+#include <linux/of_net.h>
#include "lan743x_main.h"
#include "lan743x_ethtool.h"
@@ -804,26 +805,29 @@ static int lan743x_mac_init(struct lan743x_adapter *adapter)
data |= MAC_CR_CNTR_RST_;
lan743x_csr_write(adapter, MAC_CR, data);
- mac_addr_hi = lan743x_csr_read(adapter, MAC_RX_ADDRH);
- mac_addr_lo = lan743x_csr_read(adapter, MAC_RX_ADDRL);
- adapter->mac_address[0] = mac_addr_lo & 0xFF;
- adapter->mac_address[1] = (mac_addr_lo >> 8) & 0xFF;
- adapter->mac_address[2] = (mac_addr_lo >> 16) & 0xFF;
- adapter->mac_address[3] = (mac_addr_lo >> 24) & 0xFF;
- adapter->mac_address[4] = mac_addr_hi & 0xFF;
- adapter->mac_address[5] = (mac_addr_hi >> 8) & 0xFF;
+ if (!is_valid_ether_addr(adapter->mac_address)) {
+ mac_addr_hi = lan743x_csr_read(adapter, MAC_RX_ADDRH);
+ mac_addr_lo = lan743x_csr_read(adapter, MAC_RX_ADDRL);
+ adapter->mac_address[0] = mac_addr_lo & 0xFF;
+ adapter->mac_address[1] = (mac_addr_lo >> 8) & 0xFF;
+ adapter->mac_address[2] = (mac_addr_lo >> 16) & 0xFF;
+ adapter->mac_address[3] = (mac_addr_lo >> 24) & 0xFF;
+ adapter->mac_address[4] = mac_addr_hi & 0xFF;
+ adapter->mac_address[5] = (mac_addr_hi >> 8) & 0xFF;
+
+ if (((mac_addr_hi & 0x0000FFFF) == 0x0000FFFF) &&
+ mac_addr_lo == 0xFFFFFFFF) {
+ mac_address_valid = false;
+ } else if (!is_valid_ether_addr(adapter->mac_address)) {
+ mac_address_valid = false;
+ }
- if (((mac_addr_hi & 0x0000FFFF) == 0x0000FFFF) &&
- mac_addr_lo == 0xFFFFFFFF) {
- mac_address_valid = false;
- } else if (!is_valid_ether_addr(adapter->mac_address)) {
- mac_address_valid = false;
+ if (!mac_address_valid)
+ eth_random_addr(adapter->mac_address);
}
-
- if (!mac_address_valid)
- eth_random_addr(adapter->mac_address);
lan743x_mac_set_address(adapter, adapter->mac_address);
ether_addr_copy(netdev->dev_addr, adapter->mac_address);
+
return 0;
}
@@ -2756,6 +2760,7 @@ static int lan743x_pcidev_probe(struct pci_dev *pdev,
{
struct lan743x_adapter *adapter = NULL;
struct net_device *netdev = NULL;
+ const void *mac_addr;
int ret = -ENODEV;
netdev = devm_alloc_etherdev(&pdev->dev,
@@ -2772,6 +2777,10 @@ static int lan743x_pcidev_probe(struct pci_dev *pdev,
NETIF_MSG_IFDOWN | NETIF_MSG_TX_QUEUED;
netdev->max_mtu = LAN743X_MAX_FRAME_SIZE;
+ mac_addr = of_get_mac_address(pdev->dev.of_node);
+ if (!IS_ERR(mac_addr))
+ ether_addr_copy(adapter->mac_address, mac_addr);
+
ret = lan743x_pci_init(adapter, pdev);
if (ret)
goto return_error;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/6] Add Microchip MCP25XXFD CAN driver
From: Marc Kleine-Budde @ 2020-06-17 22:36 UTC (permalink / raw)
To: Manivannan Sadhasivam, wg, kernel, linux-can, netdev,
linux-kernel, Kurt Van Dijck
In-Reply-To: <20200617165902.GB14228@x1.vandijck-laurijssen.be>
On 6/17/20 6:59 PM, Kurt Van Dijck wrote:
> I'm in the process of getting a Variscite imx8m mini SOM online, with
Have your heard about the imx8m plus? It has CAN cores! We have a board in the
office to play with. :)
> MCP2517FD. The 4.19 kernel that comes with it, has a driver that is
You shall not start projects with 1,5 years old kernel.
And you probably shall not use vendor kernel for new projects.
:D
> clearly inspired by the one of Martin Sperl (not investigated too much
> yet). I have problems of probing the chip when the bus is under full
> load (under not full load, the probing only occasionally fails) due to
> the modeswitch test.
>
> Is there a real difference in yours between the rpi and sunxi branches?
The sunxi branch has some sunxi SPI driver improvements, the rpi branch some for
the raspi SPI drivers. All branches with the same -xx should have the same
mcp25xxfd driver.
With the exception the latest version is v5.6-rpi/mcp25xxfd-20200607-41, which
is cleaned up for mainlining (it has the logging and dump stuff removed).
> Is there much evolution since -36 or would you mind to backport your
> latest -42 to 4.19?
Not much, some bus off cleanups, however I've backported all changes to
v4.19-rpi/mcp25xxfd-20200429-41 (debug and log is still included).
When you port this to your mx8 take all from (including)
097701d1ea4f can: dev: avoid long lines
to
v4.19-rpi/mcp25xxfd-20200429-41
> I will work on this the upcoming days. I can't do extensive tests, but
> rather a works-for-me test that includes bitrate probe.
> I only have 1 such board right now, and no other FD hardware.
Great, looking for feedback! Especially how the driver copes with your fully
loaded bus test.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [RESEND PATCH 1/6] dt-bindings: can: Document devicetree bindings for MCP25XXFD
From: Rob Herring @ 2020-06-17 22:16 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: wg, mkl, kernel, linux-can, netdev, linux-kernel, devicetree
In-Reply-To: <20200610074711.10969-2-manivannan.sadhasivam@linaro.org>
On Wed, Jun 10, 2020 at 01:17:06PM +0530, Manivannan Sadhasivam wrote:
> From: Martin Sperl <kernel@martin.sperl.org>
>
> Add devicetree YAML bindings for Microchip MCP25XXFD CAN controller.
>
> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> [mani: converted to YAML binding]
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/net/can/microchip,mcp25xxfd.yaml | 82 +++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
> new file mode 100644
> index 000000000000..7b87ec328515
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/can/microchip,mcp25xxfd.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip MCP25XXFD stand-alone CAN controller binding
> +
> +maintainers:
> + - Martin Sperl <kernel@martin.sperl.org>
> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> +
> +properties:
> + compatible:
> + const: microchip,mcp2517fd
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> + vdd-supply:
> + description: Regulator that powers the CAN controller
> +
> + xceiver-supply:
> + description: Regulator that powers the CAN transceiver
> +
> + microchip,clock-out-div:
> + description: Clock output pin divider
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
You can drop the 'allOf' now.
> + enum: [0, 1, 2, 4, 10]
> + default: 10
> +
> + microchip,clock-div2:
> + description: Divide the internal clock by 2
> + type: boolean
> +
> + microchip,gpio-open-drain:
> + description: Enable open-drain for all pins
> + type: boolean
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - gpio-controller
And '#gpio-cells'?
> + - vdd-supply
> + - xceiver-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + can0: can@1 {
> + compatible = "microchip,mcp2517fd";
> + reg = <1>;
> + clocks = <&clk24m>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <13 0x8>;
> + vdd-supply = <®5v0>;
> + xceiver-supply = <®5v0>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> +
> +...
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net] ionic: export features for vlans to use
From: David Miller @ 2020-06-17 22:12 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20200616150626.42738-1-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Tue, 16 Jun 2020 08:06:26 -0700
> Set up vlan_features for use by any vlans above us.
>
> Fixes: beead698b173 ("ionic: Add the basic NDO callbacks for netdev support")
> Signed-off-by: Shannon Nelson <snelson@pensando.io>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] ionic: no link check while resetting queues
From: David Miller @ 2020-06-17 22:08 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20200616011459.30966-1-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 15 Jun 2020 18:14:59 -0700
> If the driver is busy resetting queues after a change in
> MTU or queue parameters, don't bother checking the link,
> wait until the next watchdog cycle.
>
> Fixes: 987c0871e8ae ("ionic: check for linkup in watchdog")
> Signed-off-by: Shannon Nelson <snelson@pensando.io>
Applied and queued up for v5.7 -stable, thanks.
^ permalink raw reply
* Re: [PATCH][next] ethtool: ioctl: Use array_size() in copy_to_user()
From: David Miller @ 2020-06-17 22:05 UTC (permalink / raw)
To: gustavoars; +Cc: kuba, netdev, linux-kernel, gustavo, keescook
In-Reply-To: <20200615230107.GA16907@embeddedor>
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Date: Mon, 15 Jun 2020 18:01:07 -0500
> Use array_size() helper instead of the open-coded version in
> copy_to_user(). These sorts of multiplication factors need to
> be wrapped in array_size().
>
> This issue was found with the help of Coccinelle and, audited and fixed
> manually.
>
> Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Applied to net-next.
^ 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