* Re: [bpf-next PATCH 1/3] net: fix generic XDP to handle if eth header was mangled
From: Daniel Borkmann @ 2018-10-01 19:13 UTC (permalink / raw)
To: Song Liu, Jesper Dangaard Brouer
Cc: Networking, Daniel Borkmann, yoel, Alexei Starovoitov
In-Reply-To: <CAPhsuW76ancX7f1PTV4=Ur=BL7eWKVqW-mTpHE16QJTbKMjYLA@mail.gmail.com>
[ ping to Jesper wrt feedback ]
On 09/26/2018 07:36 AM, Song Liu wrote:
> On Tue, Sep 25, 2018 at 7:26 AM Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
>>
>> XDP can modify (and resize) the Ethernet header in the packet.
>>
>> There is a bug in generic-XDP, because skb->protocol and skb->pkt_type
>> are setup before reaching (netif_receive_)generic_xdp.
>>
>> This bug was hit when XDP were popping VLAN headers (changing
>> eth->h_proto), as skb->protocol still contains VLAN-indication
>> (ETH_P_8021Q) causing invocation of skb_vlan_untag(skb), which corrupt
>> the packet (basically popping the VLAN again).
>>
>> This patch catch if XDP changed eth header in such a way, that SKB
>> fields needs to be updated.
>>
>> Fixes: d445516966dc ("net: xdp: support xdp generic on virtual devices")
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>> ---
>> net/core/dev.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index ca78dc5a79a3..db6d89f536cb 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4258,6 +4258,9 @@ static u32 netif_receive_generic_xdp(struct sk_buff *skb,
>> struct netdev_rx_queue *rxqueue;
>> void *orig_data, *orig_data_end;
>> u32 metalen, act = XDP_DROP;
>> + __be16 orig_eth_type;
>> + struct ethhdr *eth;
>> + bool orig_bcast;
>> int hlen, off;
>> u32 mac_len;
>>
>> @@ -4298,6 +4301,9 @@ static u32 netif_receive_generic_xdp(struct sk_buff *skb,
>> xdp->data_hard_start = skb->data - skb_headroom(skb);
>> orig_data_end = xdp->data_end;
>> orig_data = xdp->data;
>> + eth = (struct ethhdr *)xdp->data;
>> + orig_bcast = is_multicast_ether_addr_64bits(eth->h_dest);
>> + orig_eth_type = eth->h_proto;
>>
>> rxqueue = netif_get_rxqueue(skb);
>> xdp->rxq = &rxqueue->xdp_rxq;
>> @@ -4321,6 +4327,14 @@ static u32 netif_receive_generic_xdp(struct sk_buff *skb,
>>
>> }
>>
>> + /* check if XDP changed eth hdr such SKB needs update */
>> + eth = (struct ethhdr *)xdp->data;
>> + if ((orig_eth_type != eth->h_proto) ||
>> + (orig_bcast != is_multicast_ether_addr_64bits(eth->h_dest))) {
>
> Is the actions below always correct for the condition above? Do we need
> to confirm the SKB is updated properly?
>
>> + __skb_push(skb, mac_len);
>> + skb->protocol = eth_type_trans(skb, skb->dev);
>> + }
>> +
>> switch (act) {
>> case XDP_REDIRECT:
>> case XDP_TX:
>>
^ permalink raw reply
* Re: [PATCH 0/3] bpf: allow zero-initialising hash map seed
From: Daniel Borkmann @ 2018-10-01 19:12 UTC (permalink / raw)
To: Lorenz Bauer, ast; +Cc: netdev, linux-api
In-Reply-To: <20181001104509.24211-1-lmb@cloudflare.com>
On 10/01/2018 12:45 PM, Lorenz Bauer wrote:
> This patch set adds a new flag BPF_F_ZERO_SEED, which allows
> forcing the seed used by hash maps to zero. This makes
> it possible to write deterministic tests.
>
> Based on an off-list conversation with Alexei Starovoitov and
> Daniel Borkmann.
>
> Lorenz Bauer (3):
> bpf: allow zero-initializing hash map seed
> tools: sync linux/bpf.h
> tools: add selftest for BPF_F_ZERO_SEED
>
> include/uapi/linux/bpf.h | 2 +
> kernel/bpf/hashtab.c | 8 ++-
> tools/include/uapi/linux/bpf.h | 2 +
> tools/testing/selftests/bpf/test_maps.c | 67 +++++++++++++++++++++----
> 4 files changed, 66 insertions(+), 13 deletions(-)
>
Please respin with proper SoB for each patch and non-empty commit
description. I think patch 1 should also have a more elaborate
commit description on the use case for BPF_F_ZERO_SEED, and I
think also a better comment in the uapi header that this is only
meant for testing and not production use.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Richard Weinberger @ 2018-10-01 19:10 UTC (permalink / raw)
To: Ido Schimmel
Cc: Stephen Hemminger, Florian Fainelli, bernhard.thaler,
David S. Miller, bridge, netdev, David Gstir, nikolay, roopa
In-Reply-To: <20181001190433.GA29874@splinter>
Am Montag, 1. Oktober 2018, 21:04:33 CEST schrieb Ido Schimmel:
> On Mon, Oct 01, 2018 at 08:54:08PM +0200, Richard Weinberger wrote:
> > So the only option is having a bridge and transport STP via tc-mirred
> > or patching the bridge code (what we do right now).
>
> And I vote for the first option. I understand it involves more typing,
hehe, it is not about typing. The setup is done by a script.
And we both know that getting a patch upstream is much more work than
typing a few lines of hacky bash scripts.
Since I want a decent solution and feedback I'm bringing this up here.
I could also just go with my in-house patch and don't tell anyone...
> but I see no reason to push more complexity into the kernel - and break
> standards - when you can relatively easily accomplish the same thing in
> other ways.
If having a bridge plus u32+mirred for STP bypass is the preferred solution,
I'm fine with it.
So far we use the kernel patch and didn't test the mirred-bypass a lot.
My fear was that mirred rules from eth0 to eth1 and back might cause a
loop or confuse the bridge...
> Adding Nik and Roopa who now maintain the bridge code and should
> eventually decide about this.
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Ido Schimmel @ 2018-10-01 19:04 UTC (permalink / raw)
To: Richard Weinberger
Cc: Stephen Hemminger, Florian Fainelli, bernhard.thaler,
David S. Miller, bridge, netdev, David Gstir, nikolay, roopa
In-Reply-To: <2473404.DTJdS9eVm5@blindfold>
On Mon, Oct 01, 2018 at 08:54:08PM +0200, Richard Weinberger wrote:
> So the only option is having a bridge and transport STP via tc-mirred
> or patching the bridge code (what we do right now).
And I vote for the first option. I understand it involves more typing,
but I see no reason to push more complexity into the kernel - and break
standards - when you can relatively easily accomplish the same thing in
other ways.
Adding Nik and Roopa who now maintain the bridge code and should
eventually decide about this.
^ permalink raw reply
* Re: [RFC PATCH ethtool] ethtool: better syntax for combinations of FEC modes
From: John W. Linville @ 2018-10-01 18:59 UTC (permalink / raw)
To: Edward Cree; +Cc: Michal Kubecek, netdev
In-Reply-To: <a5312743-9d54-b239-80ee-cc7aff77b6aa@solarflare.com>
Is this patch still RFC?
On Wed, Sep 19, 2018 at 05:06:25PM +0100, Edward Cree wrote:
> Instead of commas, just have them as separate argvs.
>
> The parsing state machine might look heavyweight, but it makes it easy to add
> more parameters later and distinguish parameter names from encoding names.
>
> Suggested-by: Michal Kubecek <mkubecek@suse.cz>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> ---
> ethtool.8.in | 6 +++---
> ethtool.c | 63 ++++++++++++++++------------------------------------------
> test-cmdline.c | 10 +++++-----
> 3 files changed, 25 insertions(+), 54 deletions(-)
>
> diff --git a/ethtool.8.in b/ethtool.8.in
> index 414eaa1..7ea2cc0 100644
> --- a/ethtool.8.in
> +++ b/ethtool.8.in
> @@ -390,7 +390,7 @@ ethtool \- query or control network driver and hardware settings
> .B ethtool \-\-set\-fec
> .I devname
> .B encoding
> -.BR auto | off | rs | baser [ , ...]
> +.BR auto | off | rs | baser \ [...]
> .
> .\" Adjust lines (i.e. full justification) and hyphenate.
> .ad
> @@ -1120,11 +1120,11 @@ current FEC mode, the driver or firmware must take the link down
> administratively and report the problem in the system logs for users to correct.
> .RS 4
> .TP
> -.BR encoding\ auto | off | rs | baser [ , ...]
> +.BR encoding\ auto | off | rs | baser \ [...]
>
> Sets the FEC encoding for the device. Combinations of options are specified as
> e.g.
> -.B auto,rs
> +.B encoding auto rs
> ; the semantics of such combinations vary between drivers.
> .TS
> nokeep;
> diff --git a/ethtool.c b/ethtool.c
> index 9997930..2f7e96b 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -4979,39 +4979,6 @@ static int fecmode_str_to_type(const char *str)
> return 0;
> }
>
> -/* Takes a comma-separated list of FEC modes, returns the bitwise OR of their
> - * corresponding ETHTOOL_FEC_* constants.
> - * Accepts repetitions (e.g. 'auto,auto') and trailing comma (e.g. 'off,').
> - */
> -static int parse_fecmode(const char *str)
> -{
> - int fecmode = 0;
> - char buf[6];
> -
> - if (!str)
> - return 0;
> - while (*str) {
> - size_t next;
> - int mode;
> -
> - next = strcspn(str, ",");
> - if (next >= 6) /* Bad mode, longest name is 5 chars */
> - return 0;
> - /* Copy into temp buffer and nul-terminate */
> - memcpy(buf, str, next);
> - buf[next] = 0;
> - mode = fecmode_str_to_type(buf);
> - if (!mode) /* Bad mode encountered */
> - return 0;
> - fecmode |= mode;
> - str += next;
> - /* Skip over ',' (but not nul) */
> - if (*str)
> - str++;
> - }
> - return fecmode;
> -}
> -
> static int do_gfec(struct cmd_context *ctx)
> {
> struct ethtool_fecparam feccmd = { 0 };
> @@ -5041,22 +5008,26 @@ static int do_gfec(struct cmd_context *ctx)
>
> static int do_sfec(struct cmd_context *ctx)
> {
> - char *fecmode_str = NULL;
> + enum { ARG_NONE, ARG_ENCODING } state = ARG_NONE;
> struct ethtool_fecparam feccmd;
> - struct cmdline_info cmdline_fec[] = {
> - { "encoding", CMDL_STR, &fecmode_str, &feccmd.fec},
> - };
> - int changed;
> - int fecmode;
> - int rv;
> + int fecmode = 0, newmode;
> + int rv, i;
>
> - parse_generic_cmdline(ctx, &changed, cmdline_fec,
> - ARRAY_SIZE(cmdline_fec));
> -
> - if (!fecmode_str)
> + for (i = 0; i < ctx->argc; i++) {
> + if (!strcmp(ctx->argp[i], "encoding")) {
> + state = ARG_ENCODING;
> + continue;
> + }
> + if (state == ARG_ENCODING) {
> + newmode = fecmode_str_to_type(ctx->argp[i]);
> + if (!newmode)
> + exit_bad_args();
> + fecmode |= newmode;
> + continue;
> + }
> exit_bad_args();
> + }
>
> - fecmode = parse_fecmode(fecmode_str);
> if (!fecmode)
> exit_bad_args();
>
> @@ -5265,7 +5236,7 @@ static const struct option {
> " [ all ]\n"},
> { "--show-fec", 1, do_gfec, "Show FEC settings"},
> { "--set-fec", 1, do_sfec, "Set FEC settings",
> - " [ encoding auto|off|rs|baser ]\n"},
> + " [ encoding auto|off|rs|baser [...]]\n"},
> { "-h|--help", 0, show_usage, "Show this help" },
> { "--version", 0, do_version, "Show version number" },
> {}
> diff --git a/test-cmdline.c b/test-cmdline.c
> index 9c51cca..84630a5 100644
> --- a/test-cmdline.c
> +++ b/test-cmdline.c
> @@ -268,12 +268,12 @@ static struct test_case {
> { 1, "--set-eee devname advertise foo" },
> { 1, "--set-fec devname" },
> { 0, "--set-fec devname encoding auto" },
> - { 0, "--set-fec devname encoding off," },
> - { 0, "--set-fec devname encoding baser,rs" },
> - { 0, "--set-fec devname encoding auto,auto," },
> + { 0, "--set-fec devname encoding off" },
> + { 0, "--set-fec devname encoding baser rs" },
> + { 0, "--set-fec devname encoding auto auto" },
> { 1, "--set-fec devname encoding foo" },
> - { 1, "--set-fec devname encoding auto,foo" },
> - { 1, "--set-fec devname encoding auto,," },
> + { 1, "--set-fec devname encoding auto foo" },
> + { 1, "--set-fec devname encoding none" },
> { 1, "--set-fec devname auto" },
> /* can't test --set-priv-flags yet */
> { 0, "-h" },
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Richard Weinberger @ 2018-10-01 18:54 UTC (permalink / raw)
To: Ido Schimmel, Stephen Hemminger
Cc: Florian Fainelli, bernhard.thaler, David S. Miller, bridge,
netdev, David Gstir
In-Reply-To: <20181001184821.GA29148@splinter>
Am Montag, 1. Oktober 2018, 20:48:21 CEST schrieb Ido Schimmel:
> > This is my plan b, having a u32 classifier that transports STP directly
> > to the other interface.
> > But IMHO this all is a bit hacky and a "forward anything" bridge mode
> > sounds more natural to me.
>
> But "forwarding STP and PAUSE if the number of slaves is restricted to
> 2" is a hack. The Linux bridge (like other networking equipment) needs
> to conform to standards and to the best of my knowledge what you're
> requesting is explicitly forbidden by IEEE standards.
>
> Also, if what you need is "forward anything", then Florian's suggestion
> should work for you.
Agreed, both variants are hacks. Depending on the point of view one might seem
less hacky than the other. :-)
As I said, netfilter is also part of the game. Unless I miss something, netfilter
won't see any packets if tc-mirred is used.
So the only option is having a bridge and transport STP via tc-mirred
or patching the bridge code (what we do right now).
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Ido Schimmel @ 2018-10-01 18:48 UTC (permalink / raw)
To: Richard Weinberger
Cc: Florian Fainelli, Richard Weinberger, Stephen Hemminger,
bernhard.thaler, David S. Miller, bridge, netdev, David Gstir
In-Reply-To: <2327925.x0GQ7AZp12@blindfold>
On Mon, Oct 01, 2018 at 08:32:12PM +0200, Richard Weinberger wrote:
> Am Montag, 1. Oktober 2018, 20:25:26 CEST schrieb Ido Schimmel:
> > On Mon, Oct 01, 2018 at 08:16:22PM +0200, Richard Weinberger wrote:
> > > Florian,
> > >
> > > Am Montag, 1. Oktober 2018, 18:24:25 CEST schrieb Florian Fainelli:
> > > > If all you are doing is forwarding anything, one thing I experimented
> > > > with before is the following:
> > > >
> > > > # tc qdisc add dev eth1 handle ffff: ingress
> > > > # tc qdisc add dev eth3 handle ffff: ingress
> > > > # tc filter add dev eth3 parent ffff: u32 \
> > > > > match u32 0 0 \
> > > > > action mirred egress redirect dev eth1
> > > > # tc filter add dev eth1 parent ffff: u32 \
> > > > > match u32 0 0 \
> > > > > action mirred egress redirect dev eth3
> > > > # ifconfig eth3 promisc
> > > > # ifconfig eth1 promisc
> > > >
> > > > and this works just fine actually, bypassing the bridge layer entirely.
> > >
> > > Yeah, mirred is a powerful knife. :-)
> > >
> > > In my case it is too low level since I utilize the netfilter functionality of
> > > the bridge layer.
> >
> > You can use mirred only for the specific packets you care about and let
> > the rest continue to the bridge.
>
> This is my plan b, having a u32 classifier that transports STP directly
> to the other interface.
> But IMHO this all is a bit hacky and a "forward anything" bridge mode
> sounds more natural to me.
But "forwarding STP and PAUSE if the number of slaves is restricted to
2" is a hack. The Linux bridge (like other networking equipment) needs
to conform to standards and to the best of my knowledge what you're
requesting is explicitly forbidden by IEEE standards.
Also, if what you need is "forward anything", then Florian's suggestion
should work for you.
^ permalink raw reply
* Re: [PATCH net-next] tls: Add support for inplace records encryption
From: Dave Watson @ 2018-10-01 18:33 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem, doronrk
In-Reply-To: <20180930023435.22864-1-vakul.garg@nxp.com>
On 09/30/18 08:04 AM, Vakul Garg wrote:
> Presently, for non-zero copy case, separate pages are allocated for
> storing plaintext and encrypted text of records. These pages are stored
> in sg_plaintext_data and sg_encrypted_data scatterlists inside record
> structure. Further, sg_plaintext_data & sg_encrypted_data are passed
> to cryptoapis for record encryption. Allocating separate pages for
> plaintext and encrypted text is inefficient from both required memory
> and performance point of view.
>
> This patch adds support of inplace encryption of records. For non-zero
> copy case, we reuse the pages from sg_encrypted_data scatterlist to
> copy the application's plaintext data. For the movement of pages from
> sg_encrypted_data to sg_plaintext_data scatterlists, we introduce a new
> function move_to_plaintext_sg(). This function add pages into
> sg_plaintext_data from sg_encrypted_data scatterlists.
>
> tls_do_encryption() is modified to pass the same scatterlist as both
> source and destination into aead_request_set_crypt() if inplace crypto
> has been enabled. A new ariable 'inplace_crypto' has been introduced in
> record structure to signify whether the same scatterlist can be used.
> By default, the inplace_crypto is enabled in get_rec(). If zero-copy is
> used (i.e. plaintext data is not copied), inplace_crypto is set to '0'.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Looks reasonable to me, thanks.
Reviewed-by: Dave Watson <davejwatson@fb.com>
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Richard Weinberger @ 2018-10-01 18:32 UTC (permalink / raw)
To: Ido Schimmel
Cc: Florian Fainelli, Richard Weinberger, Stephen Hemminger,
bernhard.thaler, David S. Miller, bridge, netdev, David Gstir
In-Reply-To: <20181001182526.GA28369@splinter>
Am Montag, 1. Oktober 2018, 20:25:26 CEST schrieb Ido Schimmel:
> On Mon, Oct 01, 2018 at 08:16:22PM +0200, Richard Weinberger wrote:
> > Florian,
> >
> > Am Montag, 1. Oktober 2018, 18:24:25 CEST schrieb Florian Fainelli:
> > > If all you are doing is forwarding anything, one thing I experimented
> > > with before is the following:
> > >
> > > # tc qdisc add dev eth1 handle ffff: ingress
> > > # tc qdisc add dev eth3 handle ffff: ingress
> > > # tc filter add dev eth3 parent ffff: u32 \
> > > > match u32 0 0 \
> > > > action mirred egress redirect dev eth1
> > > # tc filter add dev eth1 parent ffff: u32 \
> > > > match u32 0 0 \
> > > > action mirred egress redirect dev eth3
> > > # ifconfig eth3 promisc
> > > # ifconfig eth1 promisc
> > >
> > > and this works just fine actually, bypassing the bridge layer entirely.
> >
> > Yeah, mirred is a powerful knife. :-)
> >
> > In my case it is too low level since I utilize the netfilter functionality of
> > the bridge layer.
>
> You can use mirred only for the specific packets you care about and let
> the rest continue to the bridge.
This is my plan b, having a u32 classifier that transports STP directly
to the other interface.
But IMHO this all is a bit hacky and a "forward anything" bridge mode
sounds more natural to me.
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH net-next v6 04/23] zinc: ChaCha20 x86_64 implementation
From: Jason A. Donenfeld @ 2018-10-02 1:09 UTC (permalink / raw)
To: Borislav Petkov
Cc: Ard Biesheuvel, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Andy Polyakov, Thomas Gleixner, mingo,
X86 ML
In-Reply-To: <20180929075601.GA11115@zn.tnic>
Hi Borislav,
On Sat, Sep 29, 2018 at 9:56 AM Borislav Petkov <bp@alien8.de> wrote:
> Documentation/process/submitting-patches.rst
>
> section 12, first sentence.
>
> The SOB chain needs to clearly express the path of the patch from
> author(s) to the upstream kernel.
Thanks for the clarification.
I've received the SOB directly from the individual in question as it
traveled through an intermediate tree on its way to the tree being
submitted here. Therefore I will retain that SOB so that it shows the
full path.
Jason
^ permalink raw reply
* Re: [PATCH net-next v6 04/23] zinc: ChaCha20 x86_64 implementation
From: Jason A. Donenfeld @ 2018-10-02 1:07 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Andy Polyakov, Thomas Gleixner, mingo,
X86 ML
In-Reply-To: <CAKv+Gu9aOiYdEzHHrHFHUFK=hNfeS=zEsvMe9OWD8hEdAYkffg@mail.gmail.com>
Hi Ard,
On Fri, Sep 28, 2018 at 5:47 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> > While this is CRYPTOGAMS code, the originating code for this happens to
> > be the same as OpenSSL's commit cded951378069a478391843f5f8653c1eb5128da
> >
>
> I'd still prefer the kernel side changes to be presented as a separate
> followup patch
I've restructured things for the MIPS64 and x86_64 and it will be as
you've asked for v7.
Jason
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Ido Schimmel @ 2018-10-01 18:25 UTC (permalink / raw)
To: Richard Weinberger
Cc: Florian Fainelli, Richard Weinberger, Stephen Hemminger,
bernhard.thaler, David S. Miller, bridge, netdev, David Gstir
In-Reply-To: <3581745.3NPUBHfd8z@blindfold>
On Mon, Oct 01, 2018 at 08:16:22PM +0200, Richard Weinberger wrote:
> Florian,
>
> Am Montag, 1. Oktober 2018, 18:24:25 CEST schrieb Florian Fainelli:
> > If all you are doing is forwarding anything, one thing I experimented
> > with before is the following:
> >
> > # tc qdisc add dev eth1 handle ffff: ingress
> > # tc qdisc add dev eth3 handle ffff: ingress
> > # tc filter add dev eth3 parent ffff: u32 \
> > > match u32 0 0 \
> > > action mirred egress redirect dev eth1
> > # tc filter add dev eth1 parent ffff: u32 \
> > > match u32 0 0 \
> > > action mirred egress redirect dev eth3
> > # ifconfig eth3 promisc
> > # ifconfig eth1 promisc
> >
> > and this works just fine actually, bypassing the bridge layer entirely.
>
> Yeah, mirred is a powerful knife. :-)
>
> In my case it is too low level since I utilize the netfilter functionality of
> the bridge layer.
You can use mirred only for the specific packets you care about and let
the rest continue to the bridge.
^ permalink raw reply
* Re: WARNING in pcpu_alloc
From: Alexei Starovoitov @ 2018-10-01 18:23 UTC (permalink / raw)
To: syzbot+18628320d3b14a5c459c, Roman Gushchin
Cc: Alexei Starovoitov, Daniel Borkmann, LKML, Network Development,
syzkaller-bugs
In-Reply-To: <000000000000357da505772ec5ad@google.com>
On Mon, Oct 1, 2018 at 6:14 PM syzbot
<syzbot+18628320d3b14a5c459c@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: c5a9f9817ba5 Merge branch 'bpf-per-cpu-cgroup-local-storage'
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=175f98e6400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=443816db871edd66
> dashboard link: https://syzkaller.appspot.com/bug?extid=18628320d3b14a5c459c
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=129cbd1a400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16685ac9400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+18628320d3b14a5c459c@syzkaller.appspotmail.com
>
> ------------[ cut here ]------------
> illegal size (0) or align (8) for percpu allocation
Roman,
looks like
if (attr->value_size > PAGE_SIZE)
return ERR_PTR(-E2BIG);
is not enough, since value_size==0 needs to be rejected as well.
Could you prepare a patch?
^ permalink raw reply
* Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
From: Richard Weinberger @ 2018-10-01 18:16 UTC (permalink / raw)
To: Florian Fainelli
Cc: Richard Weinberger, Stephen Hemminger, bernhard.thaler,
David S. Miller, bridge, netdev, David Gstir
In-Reply-To: <9331d9d8-fb4b-36f3-9484-fc80f579e617@gmail.com>
Florian,
Am Montag, 1. Oktober 2018, 18:24:25 CEST schrieb Florian Fainelli:
> If all you are doing is forwarding anything, one thing I experimented
> with before is the following:
>
> # tc qdisc add dev eth1 handle ffff: ingress
> # tc qdisc add dev eth3 handle ffff: ingress
> # tc filter add dev eth3 parent ffff: u32 \
> > match u32 0 0 \
> > action mirred egress redirect dev eth1
> # tc filter add dev eth1 parent ffff: u32 \
> > match u32 0 0 \
> > action mirred egress redirect dev eth3
> # ifconfig eth3 promisc
> # ifconfig eth1 promisc
>
> and this works just fine actually, bypassing the bridge layer entirely.
Yeah, mirred is a powerful knife. :-)
In my case it is too low level since I utilize the netfilter functionality of
the bridge layer.
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH net-next v1 0/1] net/sched: Introduce the taprio scheduler
From: Vinicius Costa Gomes @ 2018-10-01 18:12 UTC (permalink / raw)
To: netdev
Cc: jesus.sanchez-palencia, henrik, richardcochran, jhs,
xiyou.wangcong, jiri, ilias.apalodimas, simon.fok
In-Reply-To: <20180929005943.12928-1-vinicius.gomes@intel.com>
Hi,
Just a small correction, one link on the cover letter is wrong.
Vinicius Costa Gomes <vinicius.gomes@intel.com> writes:
[...]
>
>
> [1] https://patchwork.ozlabs.org/cover/938991/
>
> [2] https://patchwork.ozlabs.org/cover/808504/
>
> [3] github doesn't make it clear, but the gist can be cloned like this:
> $ git clone https://gist.github.com/jeez/bd3afeff081ba64a695008dd8215866f taprio-test
>
> [4] https://github.com/vcgomes/linux/tree/taprio-v1
The correct link is:
[4] https://github.com/vcgomes/net-next
>
> [5] https://github.com/vcgomes/iproute2/tree/taprio-v1
>
>
> Vinicius Costa Gomes (1):
> tc: Add support for configuring the taprio scheduler
>
> include/uapi/linux/pkt_sched.h | 46 ++
> net/sched/Kconfig | 11 +
> net/sched/Makefile | 1 +
> net/sched/sch_taprio.c | 962 +++++++++++++++++++++++++++++++++
> 4 files changed, 1020 insertions(+)
> create mode 100644 net/sched/sch_taprio.c
>
> --
> 2.19.0
Cheers,
^ permalink raw reply
* [PATCH net] inet: frags: rework rhashtable dismantle
From: Eric Dumazet @ 2018-10-01 17:58 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, Thomas Graf, Herbert Xu
syszbot found an interesting use-after-free [1] happening
while IPv4 fragment rhashtable was destroyed at netns dismantle.
While no insertions can possibly happen at the time a dismantling
netns is destroying this rhashtable, timers can still fire and
attempt to remove elements from this rhashtable.
This is forbidden, since rhashtable_free_and_destroy() has
no synchronization against concurrent inserts and deletes.
It seems we need to clean the rhashtable before destroying it.
[1]
BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188 [inline]
BUG: KASAN: use-after-free in rhashtable_last_table+0x216/0x240 lib/rhashtable.c:217
Read of size 8 at addr ffff88019a4c8840 by task kworker/0:4/8279
CPU: 0 PID: 8279 Comm: kworker/0:4 Not tainted 4.19.0-rc5+ #61
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events rht_deferred_worker
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
__read_once_size include/linux/compiler.h:188 [inline]
rhashtable_last_table+0x216/0x240 lib/rhashtable.c:217
rht_deferred_worker+0x157/0x1de0 lib/rhashtable.c:410
process_one_work+0xc90/0x1b90 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
Allocated by task 5:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:555 [inline]
kvmalloc_node+0xb9/0xf0 mm/util.c:423
kvmalloc include/linux/mm.h:577 [inline]
kvzalloc include/linux/mm.h:585 [inline]
bucket_table_alloc+0x9a/0x4e0 lib/rhashtable.c:176
rhashtable_rehash_alloc+0x73/0x100 lib/rhashtable.c:353
rht_deferred_worker+0x278/0x1de0 lib/rhashtable.c:413
process_one_work+0xc90/0x1b90 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
Freed by task 8283:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
kvfree+0x61/0x70 mm/util.c:452
bucket_table_free+0xda/0x250 lib/rhashtable.c:108
rhashtable_free_and_destroy+0x152/0x900 lib/rhashtable.c:1163
inet_frags_exit_net+0x3d/0x50 net/ipv4/inet_fragment.c:96
ipv4_frags_exit_net+0x73/0x90 net/ipv4/ip_fragment.c:914
ops_exit_list.isra.7+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x555/0xb10 net/core/net_namespace.c:551
process_one_work+0xc90/0x1b90 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
The buggy address belongs to the object at ffff88019a4c8800
which belongs to the cache kmalloc-16384 of size 16384
The buggy address is located 64 bytes inside of
16384-byte region [ffff88019a4c8800, ffff88019a4cc800)
The buggy address belongs to the page:
page:ffffea0006693200 count:1 mapcount:0 mapping:ffff8801da802200 index:0x0 compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0006685608 ffffea0006617c08 ffff8801da802200
raw: 0000000000000000 ffff88019a4c8800 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88019a4c8700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88019a4c8780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88019a4c8800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88019a4c8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88019a4c8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
net/ipv4/inet_fragment.c | 55 ++++++++++++++++++++++++----------------
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index bcb11f3a27c0c34115af05034a5a20f57842eb0a..50d74a191ff14078bcb87c86640fe7dd342f9956 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -68,32 +68,43 @@ void inet_frags_fini(struct inet_frags *f)
}
EXPORT_SYMBOL(inet_frags_fini);
-static void inet_frags_free_cb(void *ptr, void *arg)
-{
- struct inet_frag_queue *fq = ptr;
-
- /* If we can not cancel the timer, it means this frag_queue
- * is already disappearing, we have nothing to do.
- * Otherwise, we own a refcount until the end of this function.
- */
- if (!del_timer(&fq->timer))
- return;
-
- spin_lock_bh(&fq->lock);
- if (!(fq->flags & INET_FRAG_COMPLETE)) {
- fq->flags |= INET_FRAG_COMPLETE;
- refcount_dec(&fq->refcnt);
- }
- spin_unlock_bh(&fq->lock);
-
- inet_frag_put(fq);
-}
-
void inet_frags_exit_net(struct netns_frags *nf)
{
+ struct rhashtable_iter hti;
+ struct inet_frag_queue *fq;
+
+ /* Since we want to cleanup the hashtable, make sure that
+ * we wont trigger an automatic shrinking while in our
+ * rhashtable_walk_next() loop.
+ * Also make sure that no resize is in progress.
+ */
nf->high_thresh = 0; /* prevent creation of new frags */
+ nf->rhashtable.p.automatic_shrinking = false;
+ cancel_work_sync(&nf->rhashtable.run_work);
- rhashtable_free_and_destroy(&nf->rhashtable, inet_frags_free_cb, NULL);
+ rhashtable_walk_enter(&nf->rhashtable, &hti);
+ rhashtable_walk_start(&hti);
+ while ((fq = rhashtable_walk_next(&hti)) != NULL) {
+ if (IS_ERR(fq)) /* should not happen */
+ break;
+ if (!del_timer_sync(&fq->timer))
+ continue;
+
+ spin_lock_bh(&fq->lock);
+ inet_frag_kill(fq);
+ spin_unlock_bh(&fq->lock);
+
+ inet_frag_put(fq);
+ if (need_resched()) {
+ rhashtable_walk_stop(&hti);
+ cond_resched();
+ rhashtable_walk_start(&hti);
+ }
+ }
+ rhashtable_walk_stop(&hti);
+ rhashtable_walk_exit(&hti);
+
+ rhashtable_destroy(&nf->rhashtable);
}
EXPORT_SYMBOL(inet_frags_exit_net);
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* Rapid Prototyping Services/Anby from China
From: Nancy Chiang @ 2018-10-01 17:41 UTC (permalink / raw)
To: netdev
Dear Purchasing Manager,
How are you?
This is Nancy from Anby.
We are a professional rapid prototyping,plastic and metal components processing manufacturer at Shenzhen in China for years.
We can do 3D printing, CNC milling and turning, sheet metal fabricating, Injection mold, blow mold.
If you have projects to make, pls kindly send us 3D drawing in STP file, quantity, material and finish, we will quote you immediately.
Our service is good quality, fast delivery.
Thanks and best regards
Nancy Chiang
Shenzhen Anby Technology Co., Ltd
Address: Number 8, Qiaotou, Fuyong Town, Baoan District, Shenzhen City, Guangdong Province, China
Mobile: 0086-13420952289
Skype: nancychiang7
QQ: 276337634
mail: info(at)anbytech(dot)com
^ permalink raw reply
* [net 3/3] net/mlx5e: Set vlan masks for all offloaded TC rules
From: Saeed Mahameed @ 2018-10-01 17:37 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jianbo Liu, Saeed Mahameed
In-Reply-To: <20181001173750.25772-1-saeedm@mellanox.com>
From: Jianbo Liu <jianbol@mellanox.com>
In flow steering, if asked to, the hardware matches on the first ethertype
which is not vlan. It's possible to set a rule as follows, which is meant
to match on untagged packet, but will match on a vlan packet:
tc filter add dev eth0 parent ffff: protocol ip flower ...
To avoid this for packets with single tag, we set vlan masks to tell
hardware to check the tags for every matched packet.
Fixes: 095b6cfd69ce ('net/mlx5e: Add TC vlan match parsing')
Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 52e05f3ece50..85796727093e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1368,6 +1368,9 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
*match_level = MLX5_MATCH_L2;
}
+ } else {
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, svlan_tag, 1);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, cvlan_tag, 1);
}
if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_CVLAN)) {
--
2.17.1
^ permalink raw reply related
* [net 2/3] net/mlx5: E-Switch, Fix out of bound access when setting vport rate
From: Saeed Mahameed @ 2018-10-01 17:37 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Saeed Mahameed
In-Reply-To: <20181001173750.25772-1-saeedm@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
The code that deals with eswitch vport bw guarantee was going beyond the
eswitch vport array limit, fix that. This was pointed out by the kernel
address sanitizer (KASAN).
The error from KASAN log:
[2018-09-15 15:04:45] BUG: KASAN: slab-out-of-bounds in
mlx5_eswitch_set_vport_rate+0x8c1/0xae0 [mlx5_core]
Fixes: c9497c98901c ("net/mlx5: Add support for setting VF min rate")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 2b252cde5cc2..ea7dedc2d5ad 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2000,7 +2000,7 @@ static u32 calculate_vports_min_rate_divider(struct mlx5_eswitch *esw)
u32 max_guarantee = 0;
int i;
- for (i = 0; i <= esw->total_vports; i++) {
+ for (i = 0; i < esw->total_vports; i++) {
evport = &esw->vports[i];
if (!evport->enabled || evport->info.min_rate < max_guarantee)
continue;
@@ -2020,7 +2020,7 @@ static int normalize_vports_min_rate(struct mlx5_eswitch *esw, u32 divider)
int err;
int i;
- for (i = 0; i <= esw->total_vports; i++) {
+ for (i = 0; i < esw->total_vports; i++) {
evport = &esw->vports[i];
if (!evport->enabled)
continue;
--
2.17.1
^ permalink raw reply related
* [net 1/3] net/mlx5e: Avoid unbounded peer devices when unpairing TC hairpin rules
From: Saeed Mahameed @ 2018-10-01 17:37 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Alaa Hleihel, Saeed Mahameed
In-Reply-To: <20181001173750.25772-1-saeedm@mellanox.com>
From: Alaa Hleihel <alaa@mellanox.com>
If the peer device was already unbound, then do not attempt to modify
it's resources, otherwise we will crash on dereferencing non-existing
device.
Fixes: 5c65c564c962 ("net/mlx5e: Support offloading TC NIC hairpin flows")
Signed-off-by: Alaa Hleihel <alaa@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1 +
.../net/ethernet/mellanox/mlx5/core/en/fs.h | 2 +
.../net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/en_tc.c | 62 ++++++++++++++++++-
.../ethernet/mellanox/mlx5/core/transobj.c | 5 +-
include/linux/mlx5/transobj.h | 2 +
6 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index db2cfcd21d43..0f189f873859 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -54,6 +54,7 @@
#include "en_stats.h"
#include "en/fs.h"
+extern const struct net_device_ops mlx5e_netdev_ops;
struct page_pool;
#define MLX5E_METADATA_ETHER_TYPE (0x8CE4)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/fs.h b/drivers/net/ethernet/mellanox/mlx5/core/en/fs.h
index bbf69e859b78..1431232c9a09 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/fs.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/fs.h
@@ -16,6 +16,8 @@ struct mlx5e_tc_table {
DECLARE_HASHTABLE(mod_hdr_tbl, 8);
DECLARE_HASHTABLE(hairpin_tbl, 8);
+
+ struct notifier_block netdevice_nb;
};
struct mlx5e_flow_table {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 54118b77dc1f..f291d1bf1558 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -4315,7 +4315,7 @@ static int mlx5e_xdp(struct net_device *dev, struct netdev_bpf *xdp)
}
}
-static const struct net_device_ops mlx5e_netdev_ops = {
+const struct net_device_ops mlx5e_netdev_ops = {
.ndo_open = mlx5e_open,
.ndo_stop = mlx5e_close,
.ndo_start_xmit = mlx5e_xmit,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 9fed54017659..52e05f3ece50 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2946,14 +2946,71 @@ int mlx5e_stats_flower(struct mlx5e_priv *priv,
return 0;
}
+static void mlx5e_tc_hairpin_update_dead_peer(struct mlx5e_priv *priv,
+ struct mlx5e_priv *peer_priv)
+{
+ struct mlx5_core_dev *peer_mdev = peer_priv->mdev;
+ struct mlx5e_hairpin_entry *hpe;
+ u16 peer_vhca_id;
+ int bkt;
+
+ if (!same_hw_devs(priv, peer_priv))
+ return;
+
+ peer_vhca_id = MLX5_CAP_GEN(peer_mdev, vhca_id);
+
+ hash_for_each(priv->fs.tc.hairpin_tbl, bkt, hpe, hairpin_hlist) {
+ if (hpe->peer_vhca_id == peer_vhca_id)
+ hpe->hp->pair->peer_gone = true;
+ }
+}
+
+static int mlx5e_tc_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *ndev = netdev_notifier_info_to_dev(ptr);
+ struct mlx5e_flow_steering *fs;
+ struct mlx5e_priv *peer_priv;
+ struct mlx5e_tc_table *tc;
+ struct mlx5e_priv *priv;
+
+ if (ndev->netdev_ops != &mlx5e_netdev_ops ||
+ event != NETDEV_UNREGISTER ||
+ ndev->reg_state == NETREG_REGISTERED)
+ return NOTIFY_DONE;
+
+ tc = container_of(this, struct mlx5e_tc_table, netdevice_nb);
+ fs = container_of(tc, struct mlx5e_flow_steering, tc);
+ priv = container_of(fs, struct mlx5e_priv, fs);
+ peer_priv = netdev_priv(ndev);
+ if (priv == peer_priv ||
+ !(priv->netdev->features & NETIF_F_HW_TC))
+ return NOTIFY_DONE;
+
+ mlx5e_tc_hairpin_update_dead_peer(priv, peer_priv);
+
+ return NOTIFY_DONE;
+}
+
int mlx5e_tc_nic_init(struct mlx5e_priv *priv)
{
struct mlx5e_tc_table *tc = &priv->fs.tc;
+ int err;
hash_init(tc->mod_hdr_tbl);
hash_init(tc->hairpin_tbl);
- return rhashtable_init(&tc->ht, &tc_ht_params);
+ err = rhashtable_init(&tc->ht, &tc_ht_params);
+ if (err)
+ return err;
+
+ tc->netdevice_nb.notifier_call = mlx5e_tc_netdev_event;
+ if (register_netdevice_notifier(&tc->netdevice_nb)) {
+ tc->netdevice_nb.notifier_call = NULL;
+ mlx5_core_warn(priv->mdev, "Failed to register netdev notifier\n");
+ }
+
+ return err;
}
static void _mlx5e_tc_del_flow(void *ptr, void *arg)
@@ -2969,6 +3026,9 @@ void mlx5e_tc_nic_cleanup(struct mlx5e_priv *priv)
{
struct mlx5e_tc_table *tc = &priv->fs.tc;
+ if (tc->netdevice_nb.notifier_call)
+ unregister_netdevice_notifier(&tc->netdevice_nb);
+
rhashtable_free_and_destroy(&tc->ht, _mlx5e_tc_del_flow, NULL);
if (!IS_ERR_OR_NULL(tc->t)) {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/transobj.c b/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
index d2f76070ea7c..a1ee9a8a769e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/transobj.c
@@ -475,7 +475,8 @@ static void mlx5_hairpin_destroy_queues(struct mlx5_hairpin *hp)
for (i = 0; i < hp->num_channels; i++) {
mlx5_core_destroy_rq(hp->func_mdev, hp->rqn[i]);
- mlx5_core_destroy_sq(hp->peer_mdev, hp->sqn[i]);
+ if (!hp->peer_gone)
+ mlx5_core_destroy_sq(hp->peer_mdev, hp->sqn[i]);
}
}
@@ -567,6 +568,8 @@ static void mlx5_hairpin_unpair_queues(struct mlx5_hairpin *hp)
MLX5_RQC_STATE_RST, 0, 0);
/* unset peer SQs */
+ if (hp->peer_gone)
+ return;
for (i = 0; i < hp->num_channels; i++)
mlx5_hairpin_modify_sq(hp->peer_mdev, hp->sqn[i], MLX5_SQC_STATE_RDY,
MLX5_SQC_STATE_RST, 0, 0);
diff --git a/include/linux/mlx5/transobj.h b/include/linux/mlx5/transobj.h
index 83a33a1873a6..7f5ca2cd3a32 100644
--- a/include/linux/mlx5/transobj.h
+++ b/include/linux/mlx5/transobj.h
@@ -90,6 +90,8 @@ struct mlx5_hairpin {
u32 *rqn;
u32 *sqn;
+
+ bool peer_gone;
};
struct mlx5_hairpin *
--
2.17.1
^ permalink raw reply related
* [pull request][net 0/3] Mellanox, mlx5 fixes 2018-10-01
From: Saeed Mahameed @ 2018-10-01 17:37 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
Hi Dave,
This pull request includes some fixes to mlx5 driver,
Please pull and let me know if there's any problem.
For -stable v4.11:
"6e0a4a23c59a ('net/mlx5: E-Switch, Fix out of bound access when setting vport rate')"
For -stable v4.18:
"98d6627c372a ('net/mlx5e: Set vlan masks for all offloaded TC rules')"
Thanks,
Saeed.
---
The following changes since commit 43955a45dc0b4f3be7f0c3afc0e080ed59bb5280:
netlink: fix typo in nla_parse_nested() comment (2018-09-29 11:48:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-fixes-2018-10-01
for you to fetch changes up to c219f32cd2dc6ab8dc6740ddfc219acd29913fda:
net/mlx5e: Set vlan masks for all offloaded TC rules (2018-10-01 10:21:14 -0700)
----------------------------------------------------------------
mlx5-fixes-2018-10-01
----------------------------------------------------------------
Alaa Hleihel (1):
net/mlx5e: Avoid unbounded peer devices when unpairing TC hairpin rules
Eran Ben Elisha (1):
net/mlx5: E-Switch, Fix out of bound access when setting vport rate
Jianbo Liu (1):
net/mlx5e: Set vlan masks for all offloaded TC rules
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en/fs.h | 2 +
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 65 +++++++++++++++++++++-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/transobj.c | 5 +-
include/linux/mlx5/transobj.h | 2 +
7 files changed, 76 insertions(+), 5 deletions(-)
^ permalink raw reply
* Hiking Enthusiasts List
From: Stacey Parsons @ 2018-10-01 16:39 UTC (permalink / raw)
To: netdev
Hi,
Would you be interested in acquiring an email list of "Hiking Enthusiasts" from USA?
Our Databases:-Outdoor Enthusiasts, Camping Enthusiasts, Skiers List, Scuba divers, Golfers list, Basketball Enthusiasts and many more.
Each record in the list contains Contact Name (First, Middle and Last Name), Mailing Address, List type and Opt-in email address.
Please let me know your thoughts towards procuring the Hiking Enthusiasts List.
Best Regards,
Stacey Parsons
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the net-next tree
From: Stephen Rothwell @ 2018-10-01 23:34 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Saeed Mahameed, Gavi Teitz
[-- Attachment #1: Type: text/plain, Size: 190 bytes --]
Hi all,
Commit
f128f138cc40 ("net/mlx5e: Add ethtool control of ring params to VF representors")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 11/11] net: mscc: ocelot: make use of SerDes PHYs for handling their configuration
From: Florian Fainelli @ 2018-10-01 16:29 UTC (permalink / raw)
To: Quentin Schulz
Cc: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, allan.nielsen, linux-mips,
devicetree, linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <20181001094245.cr4hdcechrqkjymq@qschulz>
On 10/01/2018 02:42 AM, Quentin Schulz wrote:
> Hi Florian,
>
> On Sat, Sep 15, 2018 at 02:25:05PM -0700, Florian Fainelli wrote:
>>
>>
>> On 09/14/18 01:16, Quentin Schulz wrote:
>>> Previously, the SerDes muxing was hardcoded to a given mode in the MAC
>>> controller driver. Now, the SerDes muxing is configured within the
>>> Device Tree and is enforced in the MAC controller driver so we can have
>>> a lot of different SerDes configurations.
>>>
>>> Make use of the SerDes PHYs in the MAC controller to set up the SerDes
>>> according to the SerDes<->switch port mapping and the communication mode
>>> with the Ethernet PHY.
>>
>> This looks good, just a few comments below:
>>
>> [snip]
>>
>>> + err = of_get_phy_mode(portnp);
>>> + if (err < 0)
>>> + ocelot->ports[port]->phy_mode = PHY_INTERFACE_MODE_NA;
>>> + else
>>> + ocelot->ports[port]->phy_mode = err;
>>> +
>>> + switch (ocelot->ports[port]->phy_mode) {
>>> + case PHY_INTERFACE_MODE_NA:
>>> + continue;
>>
>> Would not you want to issue a message indicating that the Device Tree
>> must be updated here? AFAICT with your patch series, this should no
>> longer be a condition that you will hit unless you kept the old DTB
>> around, right?
>>
>
> It'll occur for internal PHYs. On the PCB123[1], there are four of them,
> so we need to be able to give no mode in the DT for those. For the
> upcoming PCB120, there'll be 4 external PHYs that require a mode in the
> DT and 4 internal PHYs that do not require any mode. I could put a debug
> message that says this or that PHY is configured as an internal PHY but
> I wouldn't put a message that is printed with the default log level.
>
> So I think we should keep it, shouldn't we?
Internal PHYs either use a standard connection internally (e.g: GMII) or
they are using a proprietary connection interface, in which case
phy-mode = "internal" is what we defined to represent those.
>
> [1] https://elixir.bootlin.com/linux/latest/source/arch/mips/boot/dts/mscc/ocelot_pcb123.dts
>
>>> + case PHY_INTERFACE_MODE_SGMII:
>>> + phy_mode = PHY_MODE_SGMII;
>>> + break;
>>> + case PHY_INTERFACE_MODE_QSGMII:
>>> + phy_mode = PHY_MODE_QSGMII;
>>> + break;
>>> + default:
>>> + dev_err(ocelot->dev,
>>> + "invalid phy mode for port%d, (Q)SGMII only\n",
>>> + port);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + serdes = devm_of_phy_get(ocelot->dev, portnp, NULL);
>>> + if (IS_ERR(serdes)) {
>>> + err = PTR_ERR(serdes);
>>> + if (err == -EPROBE_DEFER) {
>>
>> This can be simplified into:
>>
>> if (err == -EPROBE_DEFER)
>> dev_dbg();
>> else
>> dev_err();
>> goto err_probe_ports;
>>
>
> Indeed, good catch.
>
> Thanks,
> Quentin
>
--
Florian
^ permalink raw reply
* Re: [PATCH net] rhashtable: prevent work queue schedule while dismantling
From: Eric Dumazet @ 2018-10-01 16:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf
In-Reply-To: <20181001134022.jpcunwro5nvvrbkr@gondor.apana.org.au>
On Mon, Oct 1, 2018 at 6:40 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Mon, Oct 01, 2018 at 06:16:27AM -0700, Eric Dumazet wrote:
> > syszbot found an interesting use-after-free [1] happening
> > while IPv4 fragment rhashtable was destroyed at netns dismantle.
> >
> > While no insertions can possibly happen at the time a dismantling
> > netns is destroying this rhashtable, timers can still fire and
> > attempt to remove elements from this rhashtable.
>
> Hmm, I think that's your real problem. rhashtable_free_and_destroy
> doesn't take any locks with respect to the normal insertion/removal
> path so it definitely isn't safe to call it while you're still
> invoking the normal rhashtable remove function.
>
Ah... for some reason I thought it was ok to delete elems while
rhashtable_free_and_destroy() was running.
I would love not having to use a rhashtable_walk...() to first expunge
the hash table
before rhashtable_destroy()
^ 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