* Re: [PATCH net-next 0/3] cls_flower: Offload unmasked key
From: David Miller @ 2020-06-19 20:12 UTC (permalink / raw)
To: satish.d
Cc: jhs, xiyou.wangcong, jiri, kuba, netdev, simon.horman, kesavac,
prathibha.nagooru, intiyaz.basha, jai.rana
In-Reply-To: <20200619094156.31184-1-satish.d@oneconvergence.com>
You are giving no context on what hardware and with what driver
your changes make a difference for.
This kind of context and information is required in order for
anyone to understand your changes.
We're not accepting these changes until you explain all of this.
Thank you.
^ permalink raw reply
* pull-request: ieee802154 for net 2020-06-19
From: Stefan Schmidt @ 2020-06-19 20:14 UTC (permalink / raw)
To: davem; +Cc: linux-wpan, alex.aring, netdev
Hello Dave.
An update from ieee802154 for your *net* tree.
Just two small maintenance fixes to update references to the new project
homepage.
regards
Stefan Schmidt
The following changes since commit 0ad6f6e767ec2f613418cbc7ebe5ec4c35af540c:
net: increment xmit_recursion level in dev_direct_xmit() (2020-06-18 20:47:15 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan.git tags/ieee802154-for-davem-2020-06-19
for you to fetch changes up to e795a61a85e65b4f12c2ed3529911ac0f013fa40:
MAINTAINERS: update ieee802154 project website URL (2020-06-19 22:08:11 +0200)
----------------------------------------------------------------
Stefan Schmidt (2):
docs: net: ieee802154: change link to new project URL
MAINTAINERS: update ieee802154 project website URL
Documentation/networking/ieee802154.rst | 4 ++--
MAINTAINERS | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] docs: net: ieee802154: change link to new project URL
From: Stefan Schmidt @ 2020-06-19 20:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wpan, alex.aring
In-Reply-To: <20200619.125640.2128434436244521418.davem@davemloft.net>
Hello.
On 19.06.20 21:56, David Miller wrote:
> From: Stefan Schmidt <stefan@datenfreihafen.org>
> Date: Fri, 19 Jun 2020 09:14:22 +0200
>
>> I see you marked both patches here as awaiting upstream in
>> patchwork. I am not really sure what to do best now. Am I supposed to
>> pick them up myself and send them in my usual ieee802154 pull request?
>>
>> Before you had been picking up docs and MAINTAINERS patches
>> directly. I am fine with either way. Just want to check what you
>> expect.
>
> Please put it into a pull request, thank you.
Done now.
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH net-next 0/5] cxgb4: add support for ethtool n-tuple filters
From: David Miller @ 2020-06-19 20:17 UTC (permalink / raw)
To: vishal; +Cc: netdev, nirranjan, rahul.lakkireddy
In-Reply-To: <20200619142139.27982-1-vishal@chelsio.com>
From: Vishal Kulkarni <vishal@chelsio.com>
Date: Fri, 19 Jun 2020 19:51:34 +0530
> Patch 1: Adds data structure to maintain list of filters and handles init/dinit
> of the same.
>
> Patch 2: Handles addition of filters via ETHTOOL_SRXCLSRLINS.
>
> Patch 3: Handles deletion of filtes via ETHTOOL_SRXCLSRLDEL.
>
> Patch 4: Handles viewing of added filters.
>
> Patch 5: Adds FLOW_ACTION_QUEUE support.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/3] Add Marvell 88E1340S, 88E1548P support
From: David Miller @ 2020-06-19 20:27 UTC (permalink / raw)
To: andrew; +Cc: fido_max, netdev, f.fainelli, hkallweit1, linux, kuba
In-Reply-To: <20200619145802.GJ279339@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 19 Jun 2020 16:58:02 +0200
> On Fri, Jun 19, 2020 at 11:49:01AM +0300, Maxim Kochetkov wrote:
>> This patch series add new PHY id support.
>> Russell King asked to use single style for referencing functions.
>
> Hi Maxim
>
> In future, please put which tree this patchset is for into the subject
> line:
>
> [PATCH net-next v2] ...
This patch series doesn't apply to net-next.
It probably depends upon a recent change which is only in 'net'?
^ permalink raw reply
* Re: [PATCH net-next] ipv6: icmp6: avoid indirect call for icmpv6_send()
From: David Miller @ 2020-06-19 20:30 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, kuba
In-Reply-To: <20200619172748.15279-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 19 Jun 2020 10:27:48 -0700
> If IPv6 is builtin, we do not need an expensive indirect call
> to reach cmp6_send().
^^^^^^^^^
'icmp6_send', I fixed this up for you.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][next] ethernet: ti: am65-cpsw-qos: Use struct_size() in devm_kzalloc()
From: David Miller @ 2020-06-19 20:30 UTC (permalink / raw)
To: gustavoars; +Cc: kuba, netdev, linux-kernel, gustavo
In-Reply-To: <20200619173715.GA6998@embeddedor>
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Date: Fri, 19 Jun 2020 12:37:15 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes. Also, remove unnecessary
> variable _size_.
>
> This code was detected 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, thank you.
^ permalink raw reply
* Re: [PATCH][next] net: stmmac: selftests: Use struct_size() in kzalloc()
From: David Miller @ 2020-06-19 20:33 UTC (permalink / raw)
To: gustavoars
Cc: peppe.cavallaro, alexandre.torgue, joabreu, kuba, mcoquelin.stm32,
netdev, linux-stm32, linux-arm-kernel, linux-kernel, gustavo
In-Reply-To: <20200619174154.GA21660@embeddedor>
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Date: Fri, 19 Jun 2020 12:41:54 -0500
> 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.
>
> Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
This doesn't apply to net-next.
^ permalink raw reply
* Re: [PATCH][next] cxgb4: Use struct_size() helper
From: David Miller @ 2020-06-19 20:33 UTC (permalink / raw)
To: gustavoars; +Cc: vishal, kuba, netdev, linux-kernel, gustavo
In-Reply-To: <20200619180149.GA29621@embeddedor>
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Date: Fri, 19 Jun 2020 13:01:49 -0500
> 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.
>
> Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH][next] net: dsa: sja1105: Use struct_size() in kzalloc()
From: David Miller @ 2020-06-19 20:34 UTC (permalink / raw)
To: gustavoars
Cc: olteanv, andrew, vivien.didelot, f.fainelli, kuba, linux-kernel,
netdev, gustavo
In-Reply-To: <20200619181007.GA32353@embeddedor>
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Date: Fri, 19 Jun 2020 13:10:07 -0500
> 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.
>
> Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH net v2 0/2] net: phy: MDIO bus scanning fixes
From: David Miller @ 2020-06-19 20:40 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, andrew, hkallweit1, linux, kuba, robh+dt, frowand.list,
adajunjin, alexandre.belloni, linux-kernel, devicetree
In-Reply-To: <20200619184747.16606-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 19 Jun 2020 11:47:45 -0700
> This patch series fixes two problems with the current MDIO bus scanning
> logic which was identified while moving from 4.9 to 5.4 on devices that
> do rely on scanning the MDIO bus at runtime because they use pluggable
> cards.
>
> Changes in v2:
>
> - added comment explaining the special value of -ENODEV
> - added Andrew's Reviewed-by tag
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Question on DSA switches, IGMP forwarding and switchdev
From: Daniel Mack @ 2020-06-19 21:31 UTC (permalink / raw)
To: netdev; +Cc: Ido Schimmel, Jiri Pirko, Ivan Vecera, Florian Fainelli,
Andrew Lunn
Hi,
I'm working on a custom board featuring a Marvell mv88e6085 Ethernet
switch controlled by the Linux DSA driver, and I'm facing an issue with
IGMP packet flows.
Consider two Ethernet stations, each connected to the switch on a
dedicated port. A Linux bridge combines the two ports. In my setup, I
need these two stations to send and receive multicast traffic, with IGMP
snooping enabled.
When an IGMP query enters the switch, it is redirected to the CPU port
as all 'external' ports are configured for IGMP/MLP snooping by the
driver. The issue that I'm seeing is that the Linux bridge does not
forward the IGMP frames to any other port, no matter whether the bridge
is in snooping mode or not. This needs to happen however, otherwise the
stations will not see IGMP queries, and unsolicited membership reports
are not being transferred either.
I've traced these frames through the bridge code and figured forwarding
fails in should_deliver() in net/bridge/br_forward.c because
nbp_switchdev_allowed_egress() denies it due to the fact that the frame
has already been forwarded by the same parent device. This check causes
all manual software forwarding of frames between two such switch ports
to fail. Note that IGMP traffic is the only class of communication that
is affected by this as it is not handled in hardware.
So my question now is how to fix that. Would the DSA driver need to mark
the ports as independent somehow?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/9] libbpf: generalize libbpf externs support
From: Hao Luo @ 2020-06-19 21:57 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, Networking, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Kernel Team, Arnaldo Carvalho de Melo, Song Liu,
Quentin Monnet
In-Reply-To: <20200619203026.78267-2-andriin@fb.com>
Only two small places on this version, otherwise it looks good to me.
I can offer my reviewed-by, if need. :)
Thanks for the patch!
Reviewed-by: Hao Luo <haoluo@google.com>
On Fri, Jun 19, 2020 at 1:34 PM Andrii Nakryiko <andriin@fb.com> wrote:
>
> Switch existing Kconfig externs to be just one of few possible kinds of more
> generic externs. This refactoring is in preparation for ksymbol extern
> support, added in the follow up patch. There are no functional changes
> intended.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
[...]
> @@ -2756,23 +2796,29 @@ static int cmp_externs(const void *_a, const void *_b)
[...]
> +
> + if (a->type == EXT_KCFG) {
> + /* descending order by alignment requirements */
> + if (a->kcfg.align != b->kcfg.align)
> + return a->kcfg.align > b->kcfg.align ? -1 : 1;
> + /* ascending order by size, within same alignment class */
> + if (a->kcfg.sz != b->kcfg.sz)
> + return a->kcfg.sz < b->kcfg.sz ? -1 : 1;
> + /* resolve ties by name */
> + }
> +
> return strcmp(a->name, b->name);
> }
I assume the comment /* resolve ties by name */ is intended to be
close to strcmp?
> @@ -2818,22 +2864,39 @@ static int bpf_object__collect_externs(struct bpf_object *obj)
> ext->name = btf__name_by_offset(obj->btf, t->name_off);
> ext->sym_idx = i;
> ext->is_weak = GELF_ST_BIND(sym.st_info) == STB_WEAK;
> - ext->sz = btf__resolve_size(obj->btf, t->type);
> - if (ext->sz <= 0) {
> - pr_warn("failed to resolve size of extern '%s': %d\n",
> - ext_name, ext->sz);
> - return ext->sz;
> - }
> - ext->align = btf__align_of(obj->btf, t->type);
> - if (ext->align <= 0) {
> - pr_warn("failed to determine alignment of extern '%s': %d\n",
> - ext_name, ext->align);
> - return -EINVAL;
> - }
> - ext->type = find_extern_type(obj->btf, t->type,
> - &ext->is_signed);
> - if (ext->type == EXT_UNKNOWN) {
> - pr_warn("extern '%s' type is unsupported\n", ext_name);
> +
> + ext->sec_btf_id = find_extern_sec_btf_id(obj->btf, ext->btf_id);
> + if (ext->btf_id <= 0) {
> + pr_warn("failed to find BTF for extern '%s' [%d] section: %d\n",
> + ext_name, ext->btf_id, ext->sec_btf_id);
> + return ext->sec_btf_id;
> + }
Did you mean "ext->sec_btf_id <= 0" rather than "ext->btf_id <= 0"?
^ permalink raw reply
* Re: Question on DSA switches, IGMP forwarding and switchdev
From: Andrew Lunn @ 2020-06-19 21:58 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev, Ido Schimmel, Jiri Pirko, Ivan Vecera, Florian Fainelli
In-Reply-To: <59c5ede2-8b52-c250-7396-fd7b19ec6bc7@zonque.org>
On Fri, Jun 19, 2020 at 11:31:04PM +0200, Daniel Mack wrote:
> Hi,
>
> I'm working on a custom board featuring a Marvell mv88e6085 Ethernet
> switch controlled by the Linux DSA driver, and I'm facing an issue with
> IGMP packet flows.
>
> Consider two Ethernet stations, each connected to the switch on a
> dedicated port. A Linux bridge combines the two ports. In my setup, I
> need these two stations to send and receive multicast traffic, with IGMP
> snooping enabled.
>
> When an IGMP query enters the switch, it is redirected to the CPU port
> as all 'external' ports are configured for IGMP/MLP snooping by the
> driver. The issue that I'm seeing is that the Linux bridge does not
> forward the IGMP frames to any other port, no matter whether the bridge
> is in snooping mode or not. This needs to happen however, otherwise the
> stations will not see IGMP queries, and unsolicited membership reports
> are not being transferred either.
Hi Daniel
I think all the testing i've done in this area i've had the bridge
acting as the IGMP queirer. Hence it has replied to the query, rather
than forward it out other ports.
So this could be a bug.
> I've traced these frames through the bridge code and figured forwarding
> fails in should_deliver() in net/bridge/br_forward.c because
> nbp_switchdev_allowed_egress() denies it due to the fact that the frame
> has already been forwarded by the same parent device.
To get this far, has the bridge determined it is not the elected
querier? I guess it must of done. Otherwise it would not be
forwarding it.
> So my question now is how to fix that. Would the DSA driver need to mark
> the ports as independent somehow?
The problem here is:
https://elixir.bootlin.com/linux/v5.8-rc1/source/net/dsa/tag_edsa.c#L159
Setting offload_fwd_mark means the switch has forwarded the frame as
needed to other ports of the switch. If the frame is an IGMP query
frame, and the bridge is not the elected quierer, i guess we need to
set this false? Or we need an FDB in the switch to forward it. What
group address is being used?
Andrew
^ permalink raw reply
* Re: net test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: David Howells @ 2020-06-19 22:03 UTC (permalink / raw)
To: syzbot
Cc: dhowells, davem, kuba, linux-afs, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <00000000000096141f05a845c246@google.com>
#syz dup: net-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
^ permalink raw reply
* Re: bpf-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: David Howells @ 2020-06-19 22:04 UTC (permalink / raw)
To: syzbot
Cc: dhowells, ast, daniel, linux-afs, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000006fc0b705a85afe83@google.com>
#syz dup: net-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
^ permalink raw reply
* Re: bpf test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: David Howells @ 2020-06-19 22:04 UTC (permalink / raw)
To: syzbot
Cc: dhowells, ast, daniel, linux-afs, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <00000000000042f7b405a86969e4@google.com>
#sys dup: net-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
^ permalink raw reply
* Re: net-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: David Howells @ 2020-06-19 22:12 UTC (permalink / raw)
To: syzbot
Cc: dhowells, davem, kuba, linux-afs, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000009111c005a845c2bc@google.com>
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 559f5964f95ce6096ae0aa858eaee202500ab9ca
^ permalink raw reply
* Re: Re: net-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: syzbot @ 2020-06-19 22:13 UTC (permalink / raw)
To: David Howells
Cc: davem, dhowells, kuba, linux-afs, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <2214469.1592604774@warthog.procyon.org.uk>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 559f5964f95ce6096ae0aa858eaee202500ab9ca
This crash does not have a reproducer. I cannot test it.
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/9] libbpf: generalize libbpf externs support
From: Andrii Nakryiko @ 2020-06-19 22:12 UTC (permalink / raw)
To: Hao Luo
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Arnaldo Carvalho de Melo, Song Liu,
Quentin Monnet
In-Reply-To: <CA+khW7ji5gFXh1XN71CUy08+bofu=yKfopgXV7yOuhRkoSr1=w@mail.gmail.com>
On Fri, Jun 19, 2020 at 2:57 PM Hao Luo <haoluo@google.com> wrote:
>
> Only two small places on this version, otherwise it looks good to me.
> I can offer my reviewed-by, if need. :)
>
> Thanks for the patch!
>
> Reviewed-by: Hao Luo <haoluo@google.com>
>
> On Fri, Jun 19, 2020 at 1:34 PM Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > Switch existing Kconfig externs to be just one of few possible kinds of more
> > generic externs. This refactoring is in preparation for ksymbol extern
> > support, added in the follow up patch. There are no functional changes
> > intended.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
>
> [...]
>
> > @@ -2756,23 +2796,29 @@ static int cmp_externs(const void *_a, const void *_b)
>
> [...]
>
> > +
> > + if (a->type == EXT_KCFG) {
> > + /* descending order by alignment requirements */
> > + if (a->kcfg.align != b->kcfg.align)
> > + return a->kcfg.align > b->kcfg.align ? -1 : 1;
> > + /* ascending order by size, within same alignment class */
> > + if (a->kcfg.sz != b->kcfg.sz)
> > + return a->kcfg.sz < b->kcfg.sz ? -1 : 1;
> > + /* resolve ties by name */
> > + }
> > +
> > return strcmp(a->name, b->name);
> > }
>
> I assume the comment /* resolve ties by name */ is intended to be
> close to strcmp?
yep
>
> > @@ -2818,22 +2864,39 @@ static int bpf_object__collect_externs(struct bpf_object *obj)
> > ext->name = btf__name_by_offset(obj->btf, t->name_off);
> > ext->sym_idx = i;
> > ext->is_weak = GELF_ST_BIND(sym.st_info) == STB_WEAK;
> > - ext->sz = btf__resolve_size(obj->btf, t->type);
> > - if (ext->sz <= 0) {
> > - pr_warn("failed to resolve size of extern '%s': %d\n",
> > - ext_name, ext->sz);
> > - return ext->sz;
> > - }
> > - ext->align = btf__align_of(obj->btf, t->type);
> > - if (ext->align <= 0) {
> > - pr_warn("failed to determine alignment of extern '%s': %d\n",
> > - ext_name, ext->align);
> > - return -EINVAL;
> > - }
> > - ext->type = find_extern_type(obj->btf, t->type,
> > - &ext->is_signed);
> > - if (ext->type == EXT_UNKNOWN) {
> > - pr_warn("extern '%s' type is unsupported\n", ext_name);
> > +
> > + ext->sec_btf_id = find_extern_sec_btf_id(obj->btf, ext->btf_id);
> > + if (ext->btf_id <= 0) {
> > + pr_warn("failed to find BTF for extern '%s' [%d] section: %d\n",
> > + ext_name, ext->btf_id, ext->sec_btf_id);
> > + return ext->sec_btf_id;
> > + }
>
> Did you mean "ext->sec_btf_id <= 0" rather than "ext->btf_id <= 0"?
yep, argh...
^ permalink raw reply
* [PATCH bpf-next] tools/bpftool: relicense bpftool's BPF profiler prog as dual-license GPL/BSD
From: Andrii Nakryiko @ 2020-06-19 22:20 UTC (permalink / raw)
To: bpf, netdev, ast, daniel
Cc: andrii.nakryiko, kernel-team, Andrii Nakryiko, Song Liu,
Quentin Monnet
Relicense it to be compatible with the rest of bpftool files.
Cc: Song Liu <songliubraving@fb.com>
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
tools/bpf/bpftool/skeleton/profiler.bpf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/bpf/bpftool/skeleton/profiler.bpf.c b/tools/bpf/bpftool/skeleton/profiler.bpf.c
index 20034c12f7c5..c9d196ddb670 100644
--- a/tools/bpf/bpftool/skeleton/profiler.bpf.c
+++ b/tools/bpf/bpftool/skeleton/profiler.bpf.c
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
// Copyright (c) 2020 Facebook
#include "profiler.h"
#include <linux/bpf.h>
@@ -116,4 +116,4 @@ int BPF_PROG(fexit_XXX)
return 0;
}
-char LICENSE[] SEC("license") = "GPL";
+char LICENSE[] SEC("license") = "Dual BSD/GPL";
--
2.24.1
^ permalink raw reply related
* Re: [PATCH bpf-next 1/2] bpf: switch most helper return values from 32-bit int to 64-bit long
From: Daniel Borkmann @ 2020-06-19 22:21 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: John Fastabend, Andrii Nakryiko, bpf, Networking,
Alexei Starovoitov, Kernel Team
In-Reply-To: <CAEf4Bzb-nqK0Z=GaWWejriSqqGd6D5Cz_w689N7_51D+daGyvw@mail.gmail.com>
On 6/19/20 8:41 PM, Andrii Nakryiko wrote:
> On Fri, Jun 19, 2020 at 6:08 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 6/19/20 2:39 AM, John Fastabend wrote:
>>> John Fastabend wrote:
>>>> Andrii Nakryiko wrote:
>>>>> On Thu, Jun 18, 2020 at 11:58 AM John Fastabend
>>>>> <john.fastabend@gmail.com> wrote:
>>>
>>> [...]
>>>
>>>>> That would be great. Self-tests do work, but having more testing with
>>>>> real-world application would certainly help as well.
>>>>
>>>> Thanks for all the follow up.
>>>>
>>>> I ran the change through some CI on my side and it passed so I can
>>>> complain about a few shifts here and there or just update my code or
>>>> just not change the return types on my side but I'm convinced its OK
>>>> in most cases and helps in some so...
>>>>
>>>> Acked-by: John Fastabend <john.fastabend@gmail.com>
>>>
>>> I'll follow this up with a few more selftests to capture a couple of our
>>> patterns. These changes are subtle and I worry a bit that additional
>>> <<,s>> pattern could have the potential to break something.
>>>
>>> Another one we didn't discuss that I found in our code base is feeding
>>> the output of a probe_* helper back into the size field (after some
>>> alu ops) of subsequent probe_* call. Unfortunately, the tests I ran
>>> today didn't cover that case.
>>>
>>> I'll put it on the list tomorrow and encode these in selftests. I'll
>>> let the mainainers decide if they want to wait for those or not.
>>
>> Given potential fragility on verifier side, my preference would be that we
>> have the known variations all covered in selftests before moving forward in
>> order to make sure they don't break in any way. Back in [0] I've seen mostly
>> similar cases in the way John mentioned in other projects, iirc, sysdig was
>> another one. If both of you could hack up the remaining cases we need to
>> cover and then submit a combined series, that would be great. I don't think
>> we need to rush this optimization w/o necessary selftests.
>
> There is no rush, but there is also no reason to delay it. I'd rather
> land it early in the libbpf release cycle and let people try it in
> their prod environments, for those concerned about such code patterns.
Andrii, define 'delay'. John mentioned above to put together few more
selftests today so that there is better coverage at least, why is that
an 'issue'? I'm not sure how you read 'late in release cycle' out of it,
it's still as early. The unsigned optimization for len <= MAX_LEN is
reasonable and makes sense, but it's still one [specific] variant only.
> I don't have a list of all the patterns that we might need to test.
> Going through all open-source BPF source code to identify possible
> patterns and then coding them up in minimal selftests is a bit too
> much for me, honestly.
I think we're probably talking past each other. John wrote above:
>>> I'll follow this up with a few more selftests to capture a couple of our
>>> patterns. These changes are subtle and I worry a bit that additional
>>> <<,s>> pattern could have the potential to break something.
So submitting this as a full series together makes absolutely sense to me,
so there's maybe not perfect but certainly more confidence that also other
patterns where the shifts optimized out in one case are then appearing in
another are tested on a best effort and run our kselftest suite.
Thanks,
Daniel
^ permalink raw reply
* Re: net-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: David Howells @ 2020-06-19 22:22 UTC (permalink / raw)
To: syzbot
Cc: dhowells, davem, kuba, linux-afs, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000005805de05a87732bf@google.com>
syzbot <syzbot+d3eccef36ddbd02713e9@syzkaller.appspotmail.com> wrote:
> This crash does not have a reproducer. I cannot test it.
This should do it:
insmod fs/afs/kafs.ko; rmmod kafs
David
^ permalink raw reply
* Re: [PATCH bpf-next] tools/bpftool: relicense bpftool's BPF profiler prog as dual-license GPL/BSD
From: Daniel Borkmann @ 2020-06-19 22:28 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast
Cc: andrii.nakryiko, kernel-team, Song Liu, Quentin Monnet
In-Reply-To: <20200619222024.519774-1-andriin@fb.com>
On 6/20/20 12:20 AM, Andrii Nakryiko wrote:
> Relicense it to be compatible with the rest of bpftool files.
>
> Cc: Song Liu <songliubraving@fb.com>
> Suggested-by: Quentin Monnet <quentin@isovalent.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Applied, thanks!
^ permalink raw reply
* RE: Question on DSA switches, IGMP forwarding and switchdev
From: Jason Cobham @ 2020-06-19 22:05 UTC (permalink / raw)
To: 'Andrew Lunn', Daniel Mack
Cc: netdev@vger.kernel.org, Ido Schimmel, Jiri Pirko, Ivan Vecera,
Florian Fainelli
In-Reply-To: <20200619215817.GN279339@lunn.ch>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Andrew Lunn
> Sent: Friday, June 19, 2020 2:58 PM
> To: Daniel Mack
> Cc: netdev@vger.kernel.org; Ido Schimmel; Jiri Pirko; Ivan Vecera; Florian
> Fainelli
> Subject: Re: Question on DSA switches, IGMP forwarding and switchdev
>
> On Fri, Jun 19, 2020 at 11:31:04PM +0200, Daniel Mack wrote:
> > Hi,
> >
> > I'm working on a custom board featuring a Marvell mv88e6085 Ethernet
> > switch controlled by the Linux DSA driver, and I'm facing an issue with
> > IGMP packet flows.
> >
> > Consider two Ethernet stations, each connected to the switch on a
> > dedicated port. A Linux bridge combines the two ports. In my setup, I
> > need these two stations to send and receive multicast traffic, with IGMP
> > snooping enabled.
> >
> > When an IGMP query enters the switch, it is redirected to the CPU port
> > as all 'external' ports are configured for IGMP/MLP snooping by the
> > driver. The issue that I'm seeing is that the Linux bridge does not
> > forward the IGMP frames to any other port, no matter whether the bridge
> > is in snooping mode or not. This needs to happen however, otherwise the
> > stations will not see IGMP queries, and unsolicited membership reports
> > are not being transferred either.
>
> Hi Daniel
>
> I think all the testing i've done in this area i've had the bridge
> acting as the IGMP queirer. Hence it has replied to the query, rather
> than forward it out other ports.
>
> So this could be a bug.
>
> > I've traced these frames through the bridge code and figured forwarding
> > fails in should_deliver() in net/bridge/br_forward.c because
> > nbp_switchdev_allowed_egress() denies it due to the fact that the frame
> > has already been forwarded by the same parent device.
>
> To get this far, has the bridge determined it is not the elected
> querier? I guess it must of done. Otherwise it would not be
> forwarding it.
>
> > So my question now is how to fix that. Would the DSA driver need to mark
> > the ports as independent somehow?
>
> The problem here is:
>
> https://elixir.bootlin.com/linux/v5.8-rc1/source/net/dsa/tag_edsa.c#L159
>
> Setting offload_fwd_mark means the switch has forwarded the frame as
> needed to other ports of the switch. If the frame is an IGMP query
> frame, and the bridge is not the elected quierer, i guess we need to
> set this false? Or we need an FDB in the switch to forward it. What
> group address is being used?
>
> Andrew
I've run into the same issue. To resolve it, In my case, in the same file, I've had to send all IGMP control traffic to the CPU:
skb->offload_fwd_mark = 1;
switch (ih->type) {
case IGMP_HOST_MEMBERSHIP_REPORT:
case IGMPV2_HOST_MEMBERSHIP_REPORT:
case IGMPV3_HOST_MEMBERSHIP_REPORT:
case IGMP_HOST_MEMBERSHIP_QUERY:
case IGMP_HOST_LEAVE_MESSAGE:
skb->offload_fwd_mark = 0;
break;
}
I'd be interested if there is a better way.
Jason
^ 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