* Re: [PATCH] mlxsw: core: Fix an error handling path in \'mlxsw_core_bus_device_register()\'
From: Arkadi Sharshevsky @ 2018-05-10 13:08 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180510124138.6yerbsfcl3abqtmq@mwanda>
Hi Dan,
I will fix the error path. Regarding the goto label this is
the convention in the driver.
Thanks,
Arkadi
^ permalink raw reply
* Re: [PATCH net] net: Correct wrong skb_flow_limit check when enable RPS
From: Eric Dumazet @ 2018-05-10 13:02 UTC (permalink / raw)
To: gfree.wind, davem, daniel, jakub.kicinski, dsahern, netdev
In-Reply-To: <1525940884-21067-1-git-send-email-gfree.wind@vip.163.com>
On 05/10/2018 01:28 AM, gfree.wind@vip.163.com wrote:
> From: Gao Feng <gfree.wind@vip.163.com>
>
> The skb flow limit is implemented for each CPU independently. In the
> current codes, the function skb_flow_limit gets the softnet_data by
> this_cpu_ptr. But the target cpu of enqueue_to_backlog would be not
> the current cpu when enable RPS. As the result, the skb_flow_limit checks
> the stats of current CPU, while the skb is going to append the queue of
> another CPU. It isn't the expected behavior.
>
> Now pass the softnet_data as a param to softnet_data to make consistent.
>
Please add a correct Fixes: tag
By doing so, you will likely add a CC: tag to make sure the author of the code
will receive your email and give feed back.
Thanks !
^ permalink raw reply
* [PATCH][next] net: aquantia: fix unsigned numvecs comparison with less than zero
From: Colin King @ 2018-05-10 12:52 UTC (permalink / raw)
To: David S . Miller, Igor Russkikh, Pavel Belous, Wei Yongjun,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The comparison of numvecs < 0 is always false because numvecs is a u32
and hence the error return from a failed call to pci_alloc_irq_vectores
is never detected. Fix this by using the signed int ret to handle the
error return and assign numvecs to err.
Detected by CoverityScan, CID#1468650 ("Unsigned compared against 0")
Fixes: a09bd81b5413 ("net: aquantia: Limit number of vectors to actually allocated irqs")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
index a50e08bb4748..750007513f9d 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
@@ -267,14 +267,13 @@ static int aq_pci_probe(struct pci_dev *pdev,
numvecs = min(numvecs, num_online_cpus());
/*enable interrupts */
#if !AQ_CFG_FORCE_LEGACY_INT
- numvecs = pci_alloc_irq_vectors(self->pdev, 1, numvecs,
- PCI_IRQ_MSIX | PCI_IRQ_MSI |
- PCI_IRQ_LEGACY);
+ err = pci_alloc_irq_vectors(self->pdev, 1, numvecs,
+ PCI_IRQ_MSIX | PCI_IRQ_MSI |
+ PCI_IRQ_LEGACY);
- if (numvecs < 0) {
- err = numvecs;
+ if (err < 0)
goto err_hwinit;
- }
+ numvecs = err;
#endif
self->irqvecs = numvecs;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Tariq Toukan @ 2018-05-10 12:42 UTC (permalink / raw)
To: Christophe JAILLET, davem, tariqt
Cc: netdev, linux-rdma, linux-kernel, kernel-janitors
In-Reply-To: <20180510070604.19635-1-christophe.jaillet@wanadoo.fr>
On 10/05/2018 10:06 AM, Christophe JAILLET wrote:
> If an error occurs, 'mlx4_en_destroy_netdev()' is called.
> It then calls 'mlx4_en_free_resources()' which does the needed resources
> cleanup.
>
> So, doing some explicit kfree in the error handling path would lead to
> some double kfree.
>
> Simplify code to avoid such a case.
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> v1 -> v2 : rewrite the fix as explained by Tariq Toukan
> (this 2nd version may have been posted twice, once without the
> v2 tag. PLease ignore the first one)
> ---
>
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index e0adac4a9a19..9670b33fc9b1 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -3324,12 +3324,11 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_ring[t]) {
> err = -ENOMEM;
> - goto err_free_tx;
> + goto out;
> }
> priv->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_cq[t]) {
> - kfree(priv->tx_ring[t]);
> err = -ENOMEM;
> goto out;
> }
> @@ -3582,11 +3581,6 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
>
> return 0;
>
> -err_free_tx:
> - while (t--) {
> - kfree(priv->tx_ring[t]);
> - kfree(priv->tx_cq[t]);
> - }
> out:
> mlx4_en_destroy_netdev(dev);
> return err;
>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Thanks Christophe.
^ permalink raw reply
* Re: [PATCH] mlxsw: core: Fix an error handling path in 'mlxsw_core_bus_device_register()'
From: Dan Carpenter @ 2018-05-10 12:41 UTC (permalink / raw)
To: Christophe JAILLET
Cc: jiri, idosch, davem, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20180510112616.20508-1-christophe.jaillet@wanadoo.fr>
On Thu, May 10, 2018 at 01:26:16PM +0200, Christophe JAILLET wrote:
> Resources are not freed in the reverse order of the allocation.
> Labels are also mixed-up.
>
> Fix it and reorder code and labels in the error handling path of
> 'mlxsw_core_bus_device_register()'
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> Please review carefully. This patch is proposed because it triggers one of
> my coccinelle scripts. I'm not 100% sure if correct.
>
Looks correct.
The err = mlxsw_driver->resources_register(mlxsw_core); pointer is a
pointer to mlxsw_sp_resources_register(). That function doesn't clean
up after itself on failure. Ideally, you'd want a matching
mlxsw_driver->resources_unregister as well pointer instead of hard
coding devlink_resources_unregister().
The error handling would be easier to review if the gotos told you what
the did. Right now they're written in "come from" style so the tell you
what happened on the line before.
if (!foo)
goto allocating_foo_failed;
Hopefully if someone fixes mlxsw_sp_resources_register() they'll choose
better label names.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 2/2] alx: add disable_wol paramenter
From: Andrew Lunn @ 2018-05-10 12:34 UTC (permalink / raw)
To: AceLan Kao
Cc: David Miller, James Cliburn, Chris Snook, rakesh, netdev,
Linux-Kernel@Vger. Kernel. Org, Emily Chien
In-Reply-To: <CAFv23QkETCHYqpsp_1JR30A1F=x+xCCQQv2RM9VOg24qhQRMOQ@mail.gmail.com>
On Thu, May 10, 2018 at 01:58:24PM +0800, AceLan Kao wrote:
> Hi Andrew,
>
> We have some machines using Qualcomm Atheros Killer E2400 Gigabit
> Ethernet Controller,
> but none of them has the unintentional wake up issue.
> We're willing to fix it if we encountered the issue, but before we can
> do it, we need this feature is supported by the driver.
>
> Taking the feature has been removed for 5 years into account, I doubt
> if we still can reproduce this issue,
> but again, to verify this issue we need to add back this feature first.
> Set WoL disabled by default won't introduce any regression but give
> users and developers a chance to fix it.
The main problem here is the module parameter. That is not going to be
accepted.
Can you argue the cure is worse than the disease? Is WoL not working
considered by a lot of people as being a bug? Double wake up is also a
bug, but not many people care, it does not cause any data corruption,
etc. So can you argue overall we have a less buggy system, but still
buggy, if WoL is enabled?
If you can write a convincing Change Message arguing the case, a patch
simply re-enabling WoL might be accepted.
But you also need to take on the responsibility to help debug the
failed shutdowns in order to get to the bottom of this problem.
Andrew
^ permalink raw reply
* Re: [PATCH net] tipc: eliminate KMSAN uninit-value in strcmp complaint
From: David Miller @ 2018-05-10 12:25 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, netdev, syzkaller-bugs, tipc-discussion
In-Reply-To: <1525787046-5661-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 8 May 2018 21:44:06 +0800
> When we get link properties through netlink interface with
> tipc_nl_node_get_link(), we don't validate TIPC_NLA_LINK_NAME
> attribute at all, instead we directly use it. As a consequence,
> KMSAN detected the TIPC_NLA_LINK_NAME attribute was an uninitialized
> value, and then posted the following complaint:
...
> To quiet the complaint, TIPC_NLA_LINK_NAME attribute has been
> validated in tipc_nl_node_get_link() before it's used.
>
> Reported-by: syzbot+df0257c92ffd4fcc58cd@syzkaller.appspotmail.com
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/9p: correct some comment errors in 9p file system code
From: David Miller @ 2018-05-10 12:22 UTC (permalink / raw)
To: sunlw.fnst; +Cc: viro, rdunlap, netdev
In-Reply-To: <20180508014938.28134-1-sunlw.fnst@cn.fujitsu.com>
From: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
Date: Tue, 8 May 2018 09:49:38 +0800
> There are follow comment errors:
> 1 The function name is wrong in p9_release_pages() comment.
> 2 The function name and variable name is wrong in p9_poll_workfn() comment.
> 3 There is no variable dm_mr and lkey in struct p9_trans_rdma.
> 4 The function name is wrong in rdma_create_trans() comment.
> 5 There is no variable initialized in struct virtio_chan.
> 6 The variable name is wrong in p9_virtio_zc_request() comment.
>
> Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Applied.
^ permalink raw reply
* Re: [pull request][for-next 0/6] Mellanox, mlx5 updates 2018-05-07
From: David Miller @ 2018-05-10 12:18 UTC (permalink / raw)
To: saeedm; +Cc: dledford, netdev, linux-rdma, leonro, jgg
In-Reply-To: <20180507235304.25085-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 7 May 2018 16:52:58 -0700
> This pull request includes misc updates and cleanups for mlx5 core
> driver for both net and rdma next branches, for more information please
> see tag log below.
>
> Please pull and let me know if there's any problem.
Looks good, pulled into net-next.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: bridge: Allow bridge master in br_vlan_get_info()
From: Nikolay Aleksandrov @ 2018-05-10 12:06 UTC (permalink / raw)
To: Ido Schimmel, netdev, bridge; +Cc: davem, jiri, petrm, stephen, mlxsw
In-Reply-To: <20180510101306.4891-2-idosch@mellanox.com>
On 10/05/18 13:13, Ido Schimmel wrote:
> From: Petr Machata <petrm@mellanox.com>
>
> Mirroring offload in mlxsw needs to check that a given VLAN is allowed
> to ingress the bridge device. br_vlan_get_info() is the function that is
> used for this, however currently it only supports bridge port devices.
> Extend it to support bridge masters as well.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> net/bridge/br_vlan.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index df37a5137c25..dc832c0934c6 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -1176,6 +1176,8 @@ int br_vlan_get_info(const struct net_device *dev, u16 vid,
> p = br_port_get_check_rtnl(dev);
> if (p)
> vg = nbp_vlan_group(p);
> + else if (netif_is_bridge_master(dev))
> + vg = br_vlan_group(netdev_priv(dev));
> else
> return -EINVAL;
>
>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH net] sctp: remove sctp_chunk_put from fail_mark err path in sctp_ulpevent_make_rcvmsg
From: Neil Horman @ 2018-05-10 11:58 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner,
syzkaller
In-Reply-To: <e4d7cf118c028ed05c9005951e30babc8bb300eb.1525944853.git.lucien.xin@gmail.com>
On Thu, May 10, 2018 at 05:34:13PM +0800, Xin Long wrote:
> In Commit 1f45f78f8e51 ("sctp: allow GSO frags to access the chunk too"),
> it held the chunk in sctp_ulpevent_make_rcvmsg to access it safely later
> in recvmsg. However, it also added sctp_chunk_put in fail_mark err path,
> which is only triggered before holding the chunk.
>
> syzbot reported a use-after-free crash happened on this err path, where
> it shouldn't call sctp_chunk_put.
>
> This patch simply removes this call.
>
> Fixes: 1f45f78f8e51 ("sctp: allow GSO frags to access the chunk too")
> Reported-by: syzbot+141d898c5f24489db4aa@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/ulpevent.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
> index 84207ad..8cb7d98 100644
> --- a/net/sctp/ulpevent.c
> +++ b/net/sctp/ulpevent.c
> @@ -715,7 +715,6 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
> return event;
>
> fail_mark:
> - sctp_chunk_put(chunk);
> kfree_skb(skb);
> fail:
> return NULL;
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] mlxsw: core: Fix an error handling path in 'mlxsw_core_bus_device_register()'
From: Ido Schimmel @ 2018-05-10 11:58 UTC (permalink / raw)
To: Christophe JAILLET
Cc: jiri, idosch, davem, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20180510112616.20508-1-christophe.jaillet@wanadoo.fr>
On Thu, May 10, 2018 at 01:26:16PM +0200, Christophe JAILLET wrote:
> Resources are not freed in the reverse order of the allocation.
> Labels are also mixed-up.
>
> Fix it and reorder code and labels in the error handling path of
> 'mlxsw_core_bus_device_register()'
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
For net:
Fixes: ef3116e5403e ("mlxsw: spectrum: Register KVD resources with devlink")
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Next time, please indicate the tree you're targeting as explained here:
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
And include a Fixes line as explained here:
https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
Thanks!
^ permalink raw reply
* [PATCH] mlxsw: core: Fix an error handling path in 'mlxsw_core_bus_device_register()'
From: Christophe JAILLET @ 2018-05-10 11:26 UTC (permalink / raw)
To: jiri, idosch, davem
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
Resources are not freed in the reverse order of the allocation.
Labels are also mixed-up.
Fix it and reorder code and labels in the error handling path of
'mlxsw_core_bus_device_register()'
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Please review carefully. This patch is proposed because it triggers one of
my coccinelle scripts. I'm not 100% sure if correct.
The script tries to spot wrongly ordered error handling path. It is:
@@
identifier l1, l2;
@@
if (...) {
...
* goto l1;
}
...
if (...) {
...
* goto l2;
}
...
*l1:
...
*l2:
...
---
drivers/net/ethernet/mellanox/mlxsw/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core.c b/drivers/net/ethernet/mellanox/mlxsw/core.c
index 93ea56620a24..e13ac3b8dff7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core.c
@@ -1100,11 +1100,11 @@ int mlxsw_core_bus_device_register(const struct mlxsw_bus_info *mlxsw_bus_info,
err_alloc_lag_mapping:
mlxsw_ports_fini(mlxsw_core);
err_ports_init:
- mlxsw_bus->fini(bus_priv);
-err_bus_init:
if (!reload)
devlink_resources_unregister(devlink, NULL);
err_register_resources:
+ mlxsw_bus->fini(bus_priv);
+err_bus_init:
if (!reload)
devlink_free(devlink);
err_devlink_alloc:
--
2.17.0
^ permalink raw reply related
* Re: [RFC v3 3/5] virtio_ring: add packed ring support
From: Tiwei Bie @ 2018-05-10 10:50 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, wexu, virtualization, linux-kernel, mst
In-Reply-To: <2fc35cd5-9dbd-7743-497f-b6637d92f528@redhat.com>
On Thu, May 10, 2018 at 05:49:20PM +0800, Jason Wang wrote:
> On 2018年05月10日 16:56, Tiwei Bie wrote:
> > On Thu, May 10, 2018 at 03:34:50PM +0800, Jason Wang wrote:
> > > On 2018年05月10日 15:32, Jason Wang wrote:
> > > > On 2018年04月25日 13:15, Tiwei Bie wrote:
> > > > > + /* We're using some buffers from the free list. */
> > > > > + vq->vq.num_free -= descs_used;
> > > > > +
> > > > > + /* Update free pointer */
> > > > > + if (indirect) {
> > > > > + n = head + 1;
> > > > > + if (n >= vq->vring_packed.num) {
> > > > > + n = 0;
> > > > > + vq->wrap_counter ^= 1;
> > > > > + }
> > > > > + vq->next_avail_idx = n;
> > > > > + } else
> > > > > + vq->next_avail_idx = i;
> > > > During testing zerocopy (out of order completion), I found driver may
> > > > submit two identical buffer id to vhost. So the above code may not work
> > > > well.
> > > >
> > > > Consider the case that driver adds 3 buffer and virtqueue size is 8.
> > > >
> > > > a) id = 0,count = 2,next_avail = 2
> > > >
> > > > b) id = 2,count = 4,next_avail = 2
> > > next_avail should be 6 here.
> > >
> > > > c) id = 4,count = 2,next_avail = 0
> > > >
> > > id should be 6 here.
> > >
> > > Thanks
> > >
> > > > if packet b is done before packet a, driver may think buffer id 0 is
> > > > available and try to use it if even if the real buffer 0 was not done.
> > > >
> > > > Thanks
> > Nice catch! Thanks a lot!
> > I'll implement an ID allocator.
> >
> > Best regards,
> > Tiwei Bie
>
> Sounds good.
>
> Another similar issue is detac_buf_packed(). It did:
>
> for (j = 0; j < vq->desc_state[head].num; j++) {
> desc = &vq->vring_packed.desc[i];
> vring_unmap_one_packed(vq, desc);
> i++;
> if (i >= vq->vring_packed.num)
> i = 0;
> }
>
> This probably won't work for out of order too and according to the spec:
>
> """
> Driver needs to keep track of the size of the list corresponding to each
> buffer ID, to be able to skip to where the next used descriptor is written
> by the device.
> """
>
> Looks like we should not depend on the descriptor ring.
Yeah, the previous ID allocation is too simple..
Let me fix it in the next version.
Thanks!
>
> Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto
From: Borislav Petkov @ 2018-05-10 10:49 UTC (permalink / raw)
To: Yonghong Song
Cc: peterz, mingo, torvalds, ast, daniel, linux-kernel, x86, netdev,
kernel-team
In-Reply-To: <20180504033119.2130788-1-yhs@fb.com>
On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
> Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
> removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
> use __always_inline function _static_cpu_has() funciton.
> The static_cpu_has() uses gcc feature asm goto construct,
> which is not supported by clang.
>
> Issues
> ======
>
> Currently, for BPF programs written in C, the only widely-supported
> compiler is clang. Because of clang lacking support
> of asm goto construct, if you try to compile
> bpf programs under samples/bpf/,
> $ make -j20 && make headers_install && make samples/bpf/
> you will see a lot of failures like below:
>
> clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include \
> -I/home/yhs/work/bpf-next/arch/x86/include \
> -I./arch/x86/include/generated -I/home/yhs/work/bpf-next/include \
> -I./include -I/home/yhs/work/bpf-next/arch/x86/include/uapi \
> -I./arch/x86/include/generated/uapi \
> -I/home/yhs/work/bpf-next/include/uapi -I./include/generated/uapi \
> -include /home/yhs/work/bpf-next/include/linux/kconfig.h
> -Isamples/bpf \
> -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/ \
> -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
> -D__TARGET_ARCH_x86 -Wno-compare-distinct-pointer-types \
> -Wno-gnu-variable-sized-type-not-at-end \
> -Wno-address-of-packed-member -Wno-tautological-compare \
> -Wno-unknown-warning-option \
> -O2 -emit-llvm -c /home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c \
> -o -| llc -march=bpf -filetype=obj -o samples/bpf/xdp_redirect_cpu_kern.o
> In file included from /home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c:10:
This is not the kernel's problem.
Fix the samples to build successfully like the rest of the things in
tools/ use kernel machinery and undefine/redefine stuff so that it
builds. For example, tools/include/asm/alternative-asm.h redefines two
macros. So do something along those lines.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [RFC PATCH 5/5] net: macb: Add WOL support with ARP
From: Harini Katakam @ 2018-05-10 10:37 UTC (permalink / raw)
To: Claudiu Beznea
Cc: Nicolas Ferre, David Miller, netdev, linux-kernel, michals,
appanad
In-Reply-To: <51e1b2f3-4dd7-3513-2148-649372775130@microchip.com>
Hi Claudiu,
On Fri, May 4, 2018 at 5:47 PM, Claudiu Beznea
<Claudiu.Beznea@microchip.com> wrote:
>
>
> On 22.03.2018 15:51, harinikatakamlinux@gmail.com wrote:
>> From: Harini Katakam <harinik@xilinx.com>
>>
>> This patch enables ARP wake event support in GEM through the following:
>>
>> -> WOL capability can be selected based on the SoC/GEM IP version rather
>> than a devictree property alone. Hence add a new capability property and
>> set device as "wakeup capable" in probe in this case.
>> -> Wake source selection can be done via ethtool or by enabling wakeup
>> in /sys/devices/platform/..../ethx/power/
>> This patch adds default wake source as ARP and the existing selection of
>> WOL using magic packet remains unchanged.
>> -> When GEM is the wake device with ARP as the wake event, the current
>> IP address to match is written to WOL register along with other
>> necessary confuguration required for MAC to recognize an ARP event.
>> -> While RX needs to remain enabled, there is no need to process the
>> actual wake packet - hence tie off all RX queues to avoid unnecessary
>> processing by DMA in the background.
>
> Why is this different for magic packet vs ARP packet?
This should ideally be the same whether it is a magic packet or ARP on
the version of the IP we use (more details in my comment below).
I simply did not alter the magic packet code for now to avoid breaking
others' flow.
<snip>
>> +#define MACB_CAPS_WOL 0x00000080
>
> I think would be better to have this as part of bp->wol and use it properly
> in suspend/resume hooks.
I think a capability flag as part of config structure is better
because this is clearly an SoC related feature and there is no need
to have a devicetree property.
<snip>
> Wouldn't it work if you will change it in something like this:
>
> u32 wolmask, arpipmask = 0;
>
> if (bp->wol & MACB_WOL_ENABLED) {
> macb_writel(bp, IER, MACB_BIT(WOL));
>
> if (bp->wol & MACB_WOL_HAS_ARP_PACKET) {
> /* Enable broadcast. */
> gem_writel(bp, NCFGR, gem_readl(bp, NCFGR) & ~MACB_BIT(NBC));
> arpipmask = cpu_to_be32p(&bp->dev->ip_ptr->ifa_list->ifa_local) & 0xFFFF;
> wolmask = arpipmask | MACB_BIT(ARP);
> } else {
> wolmask = MACB_BIT(MAG);
> }
>
> macb_writel(bp, WOL, wolmask);
> enable_irq_wake(bp->queues[0].irq);
The above would work. But I'd still have to add the RX BD changes
and then stop the phy, disable interrupt etc., for most optimal power
down state - the idea is to keep only is essential to detect a wake event.
> netif_device_detach(netdev);
> }
>
> I cannot find anything particular for ARP WOL events in datasheet. Also,
> I cannot find something related to DMA activity while WOL is active
Can you please let me know which version you are referring to?
ZynqMP uses the IP version r1p06 or 07.
There is a clear set of rules for ARP wake event to be recognized.
About the DMA activity, it is not explicitly mentioned but we have
observed that the DMA will continue to process incoming packets
and try to write them to the memory and Cadence has confirmed
the same. Later versions of the IP may have some provision to
stop DMA activity on RX channel but unfortunately in this version,
using a dummy RX buffer descriptor is the only way.
I'm looking into your other suggestions.
Thanks, will get back to you.
Regards,
Harini
^ permalink raw reply
* [PATCH net-next] cxgb4: fix the wrong conversion of Mbps to Kbps
From: Ganesh Goudar @ 2018-05-10 10:37 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Ganesh Goudar
fix the wrong conversion where 1 Mbps was converted to
1024 Kbps.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 32cad0a..5e33780 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -2886,13 +2886,13 @@ static int cxgb_set_tx_maxrate(struct net_device *dev, int index, u32 rate)
}
/* Convert from Mbps to Kbps */
- req_rate = rate << 10;
+ req_rate = rate * 1000;
/* Max rate is 100 Gbps */
- if (req_rate >= SCHED_MAX_RATE_KBPS) {
+ if (req_rate > SCHED_MAX_RATE_KBPS) {
dev_err(adap->pdev_dev,
"Invalid rate %u Mbps, Max rate is %u Mbps\n",
- rate, SCHED_MAX_RATE_KBPS >> 10);
+ rate, SCHED_MAX_RATE_KBPS / 1000);
return -ERANGE;
}
--
2.1.0
^ permalink raw reply related
* Re: net: hang in unregister_netdevice: waiting for lo to become free
From: Dan Streetman @ 2018-05-10 10:23 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Tommi Rantala, Neil Horman, Xin Long, David Ahern,
Daniel Borkmann, Cong Wang, David Miller, Eric Dumazet,
Willem de Bruijn, Jakub Kicinski, Rasmus Villemoes, netdev, LKML,
Alexey Kuznetsov, Hideaki YOSHIFUJI, syzkaller, Dan Streetman,
Eric W. Biederman, Alexey Kodanev
In-Reply-To: <CACT4Y+avGQk4X=GmngAs5GE8DUWFwZ5nWQD+JrurZbL181AF6w@mail.gmail.com>
On Thu, May 10, 2018 at 2:46 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Apr 16, 2018 at 9:42 PM, Dan Streetman <ddstreet@ieee.org> wrote:
>>>>>> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
>>>>>> <tommi.t.rantala@nokia.com> wrote:
>>>>>>> On 20.02.2018 18:26, Neil Horman wrote:
>>>>>>>>
>>>>>>>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
>>>>>>>>> <tommi.t.rantala@nokia.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 19.02.2018 20:59, Dmitry Vyukov wrote:
>>>>>>>>>>>
>>>>>>>>>>> Is this meant to be fixed already? I am still seeing this on the
>>>>>>>>>>> latest upstream tree.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> These two commits are in v4.16-rc1:
>>>>>>>>>>
>>>>>>>>>> commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
>>>>>>>>>> Author: Tommi Rantala <tommi.t.rantala@nokia.com>
>>>>>>>>>> Date: Mon Feb 5 21:48:14 2018 +0200
>>>>>>>>>>
>>>>>>>>>> sctp: fix dst refcnt leak in sctp_v4_get_dst
>>>>>>>>>> ...
>>>>>>>>>> Fixes: 410f03831 ("sctp: add routing output fallback")
>>>>>>>>>> Fixes: 0ca50d12f ("sctp: fix src address selection if using
>>>>>>>>>> secondary
>>>>>>>>>> addresses")
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
>>>>>>>>>> Author: Alexey Kodanev <alexey.kodanev@oracle.com>
>>>>>>>>>> Date: Mon Feb 5 15:10:35 2018 +0300
>>>>>>>>>>
>>>>>>>>>> sctp: fix dst refcnt leak in sctp_v6_get_dst()
>>>>>>>>>> ...
>>>>>>>>>> Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using
>>>>>>>>>> secondary
>>>>>>>>>> addresses for ipv6")
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I guess we missed something if it's still reproducible.
>>>>>>>>>>
>>>>>>>>>> I can check it later this week, unless someone else beat me to it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Tommi,
>>>>>>>>>
>>>>>>>>> Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
>>>>>>>>> another one then. But I am still seeing these:
>>>>>>>>>
>>>>>>>>> [ 58.799130] unregister_netdevice: waiting for lo to become free.
>>>>>>>>> Usage count = 4
>>>>>>>>> [ 60.847138] unregister_netdevice: waiting for lo to become free.
>>>>>>>>> Usage count = 4
>>>>>>>>> [ 62.895093] unregister_netdevice: waiting for lo to become free.
>>>>>>>>> Usage count = 4
>>>>>>>>> [ 64.943103] unregister_netdevice: waiting for lo to become free.
>>>>>>>>> Usage count = 4
>>>>>>>>>
>>>>>>>>> on upstream tree pulled ~12 hours ago.
>>>>>>>>>
>>>>>>>> Can you write a systemtap script to probe dev_hold, and dev_put, printing
>>>>>>>> out a
>>>>>>>> backtrace if the device name matches "lo". That should tell us
>>>>>>>> definitively if
>>>>>>>> the problem is in the same location or not
>>>>>>>
>>>>>>>
>>>>>>> Hi Dmitry, I tested with the reproducer and the kernel .config file that you
>>>>>>> sent in the first email in this thread:
>>>>>>>
>>>>>>> With 4.16-rc2 unable to reproduce.
>>>>>>>
>>>>>>> With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting for
>>>>>>> lo to become free. Usage count = 3"
>>>>>>>
>>>>>>> With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in sctp_v6_get_dst()"
>>>>>>> cherry-picked on top, unable to reproduce.
>>>>>>>
>>>>>>>
>>>>>>> Is syzkaller doing something else now to trigger the bug...?
>>>>>>> Can you still trigger the bug with the same reproducer?
>>>>>>
>>>>>> Hi Neil, Tommi,
>>>>>>
>>>>>> Reviving this old thread about "unregister_netdevice: waiting for lo
>>>>>> to become free. Usage count = 3" hangs.
>>>>>> I still did not have time to deep dive into what happens there (too
>>>>>> many bugs coming from syzbot). But this still actively happens and I
>>>>>> suspect accounts to a significant portion of various hang reports,
>>>>>> which are quite unpleasant.
>>>>>>
>>>>>> One idea that could make it all simpler:
>>>>>>
>>>>>> Is this wait loop in netdev_wait_allrefs() supposed to wait for any
>>>>>> prolonged periods of time under any non-buggy conditions? E.g. more
>>>>>> than 1-2 minutes?
>>>>>> If it only supposed to wait briefly for things that already supposed
>>>>>> to be shutting down, and we add a WARNING there after some timeout,
>>>>>> then syzbot will report all info how/when it happens, hopefully
>>>>>> extracting reproducers, and all the nice things.
>>>>>> But this WARNING should not have any false positives under any
>>>>>> realistic conditions (e.g. waiting for arrival of remote packets with
>>>>>> large timeouts).
>>>>>>
>>>>>> Looking at some task hung reports, it seems that this code holds some
>>>>>> mutexes, takes workqueue thread and prevents any progress with
>>>>>> destruction of other devices (and net namespace creation/destruction),
>>>>>> so I guess it should not wait for any indefinite periods of time?
>>>>>
>>>>> I'm working on this currently:
>>>>> https://bugs.launchpad.net/ubuntu/zesty/+source/linux/+bug/1711407
>>>>>
>>>>> I added a summary of what I've found to be the cause (or at least, one
>>>>> possible cause) of this:
>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/72
>>>>>
>>>>> I'm working on a patch to work around the main side-effect of this,
>>>>> which is hanging while holding the global net mutex. Hangs will still
>>>>> happen (e.g. if a dst leaks) but should not affect anything else,
>>>>> other than a leak of the dst and its net namespace.
>>>>>
>>>>> Fixing the dst leaks is important too, of course, but a dst leak (or
>>>>> other cause) shouldn't break the entire system.
>>>>
>>>> Leaking some memory is definitely better than hanging the system.
>>>>
>>>> So I've made syzkaller to recognize "unregister_netdevice: waiting for
>>>> (.*) to become free" as a kernel bug:
>>>> https://github.com/google/syzkaller/commit/7a67784ca8bdc3b26cce2f0ec9a40d2dd9ec9396
>>>> Unfortunately it does not make it catch these bugs because creating a
>>>> net namespace per test is too damn slow, so namespaces are reused for
>>>> lots of tests and when/if it's eventually destroyed it's already too
>>>> late to find root cause.
>>>>
>>>> But I've run a one-off experiment with prompt net namespace
>>>> destruction and syzkaller was able to easily extract a C reproducer:
>>>> https://gist.githubusercontent.com/dvyukov/d571e8fff24e127ca48a8c4790d42bfa/raw/52050e93ba9afbb5126b9d7bb39b7e71a82af016/gistfile1.txt
>>>>
>>>> On upstream 16e205cf42da1f497b10a4a24f563e6c0d574eec with this config:
>>>> https://gist.githubusercontent.com/dvyukov/9663c57443adb21f2795b92ef0829d62/raw/bbea0652e23746096dd56855a28f6c681aebcdee/gistfile1.txt
>>>>
>>>> this gives me:
>>>>
>>>> [ 83.183198] unregister_netdevice: waiting for lo to become free.
>>>> Usage count = 9
>>>> [ 85.231202] unregister_netdevice: waiting for lo to become free.
>>>> Usage count = 9
>>>> ...
>>>> [ 523.511205] unregister_netdevice: waiting for lo to become free.
>>>> Usage count = 9
>>>> ...
>>>>
>>>> This is generated from this syzkaller program:
>>>>
>>>> r0 = socket$inet6(0xa, 0x1, 0x84)
>>>> setsockopt$inet6_IPV6_XFRM_POLICY(r0, 0x29, 0x23,
>>>> &(0x7f0000000380)={{{@in6=@remote={0xfe, 0x80, [], 0xbb},
>>>> @in=@dev={0xac, 0x14, 0x14}, 0x0, 0x0, 0x0, 0x0, 0xa}, {}, {}, 0x0,
>>>> 0x0, 0x1}, {{@in=@local={0xac, 0x14, 0x14, 0xaa}, 0x0, 0x32}, 0x0,
>>>> @in=@local={0xac, 0x14, 0x14, 0xaa}, 0x3504}}, 0xe8)
>>>> bind$inet6(r0, &(0x7f0000000000)={0xa, 0x4e20}, 0x1c)
>>>> connect$inet(r0, &(0x7f0000000040)={0x2, 0x4e20, @dev={0xac, 0x14,
>>>> 0x14, 0xd}}, 0x10)
>>>> syz_emit_ethernet(0x3e, &(0x7f00000001c0)={@local={[0xaa, 0xaa, 0xaa,
>>>> 0xaa, 0xaa], 0xaa}, @dev={[0xaa, 0xaa, 0xaa, 0xaa, 0xaa]}, [],
>>>> {@ipv6={0x86dd, {0x0, 0x6, "50a09c", 0x8, 0xffffff11, 0x0,
>>>> @remote={0xfe, 0x80, [], 0xbb}, @local={0xfe, 0x80, [], 0xaa}, {[],
>>>> @udp={0x0, 0x4e20, 0x8}}}}}}, &(0x7f0000000040))
>>>>
>>>> So this seems to be related to IPv6 and/or xfrm and is potentially
>>>> caused by external packets (that syz_emit_ethernet call).
>>>
>>>
>>>
>>> Here is another repro which seems to be a different bug (note that it
>>> requires fault injection):
>>>
>>> https://gist.githubusercontent.com/dvyukov/1c56623016cc4c24a69d433c5114ad5b/raw/530478f571b195193101b912aa646948528baa8e/gistfile1.txt
>>>
>>> Dan, do you mind taking a look at them? Fixing these should eliminate
>>> root causes of these hangs/leaks.
>>
>> Yep I will look at them, thanks for the reproducers.
>
> Hi Dan,
>
> Any updates on this? syzbot is hitting this all the time.
Sorry, the recent changes from net_mutex -> net_rwsem/pernet_ops_rwsem
have complicated what I had done to workaround this, but I'm still
working on it. Apologies for the delay.
^ permalink raw reply
* [PATCH net-next 4/4] mlxsw: spectrum_span: Support VLAN under mirror-to-gretap
From: Ido Schimmel @ 2018-05-10 10:13 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, stephen, nikolay, mlxsw, Ido Schimmel
In-Reply-To: <20180510101306.4891-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
When mirroring to a gretap or ip6gretap device, allow the underlay
packet path to include VLAN devices. The following configurations are
supported in underlay:
- vlan over phys
- vlan-unaware bridge where the egress device is vlan over phys
- vlan over vlan-aware bridge where the egress device is phys
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 27 +++++++++++++++-------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index d90582ee478f..3b77990df599 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -176,21 +176,23 @@ mlxsw_sp_span_entry_bridge_8021q(const struct net_device *br_dev,
{
struct bridge_vlan_info vinfo;
struct net_device *edev;
- u16 pvid;
+ u16 vid = *p_vid;
- if (WARN_ON(br_vlan_get_pvid(br_dev, &pvid)))
+ if (!vid && WARN_ON(br_vlan_get_pvid(br_dev, &vid)))
return NULL;
- if (!pvid)
+ if (!vid ||
+ br_vlan_get_info(br_dev, vid, &vinfo) ||
+ !(vinfo.flags & BRIDGE_VLAN_INFO_BRENTRY))
return NULL;
- edev = br_fdb_find_port(br_dev, dmac, pvid);
+ edev = br_fdb_find_port(br_dev, dmac, vid);
if (!edev)
return NULL;
- if (br_vlan_get_info(edev, pvid, &vinfo))
+ if (br_vlan_get_info(edev, vid, &vinfo))
return NULL;
if (!(vinfo.flags & BRIDGE_VLAN_INFO_UNTAGGED))
- *p_vid = pvid;
+ *p_vid = vid;
return edev;
}
@@ -208,13 +210,13 @@ mlxsw_sp_span_entry_bridge(const struct net_device *br_dev,
{
struct mlxsw_sp_bridge_port *bridge_port;
enum mlxsw_reg_spms_state spms_state;
+ struct net_device *dev = NULL;
struct mlxsw_sp_port *port;
- struct net_device *dev;
u8 stp_state;
if (br_vlan_enabled(br_dev))
dev = mlxsw_sp_span_entry_bridge_8021q(br_dev, dmac, p_vid);
- else
+ else if (!*p_vid)
dev = mlxsw_sp_span_entry_bridge_8021d(br_dev, dmac);
if (!dev)
return NULL;
@@ -261,12 +263,21 @@ mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
if (!l3edev || mlxsw_sp_span_dmac(tbl, &gw, l3edev, dmac))
goto unoffloadable;
+ if (is_vlan_dev(l3edev))
+ l3edev = mlxsw_sp_span_entry_vlan(l3edev, &vid);
+
if (netif_is_bridge_master(l3edev)) {
l3edev = mlxsw_sp_span_entry_bridge(l3edev, dmac, &vid);
if (!l3edev)
goto unoffloadable;
}
+ if (is_vlan_dev(l3edev)) {
+ if (vid || !(l3edev->flags & IFF_UP))
+ goto unoffloadable;
+ l3edev = mlxsw_sp_span_entry_vlan(l3edev, &vid);
+ }
+
if (!mlxsw_sp_port_dev_check(l3edev))
goto unoffloadable;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 3/4] mlxsw: spectrum_span: Support mirror-to-VLAN
From: Ido Schimmel @ 2018-05-10 10:13 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, stephen, nikolay, mlxsw, Ido Schimmel
In-Reply-To: <20180510101306.4891-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Offload "tc action mirred mirror" to a device that is a vlan device on
top of a front-panel port device. The hardware encapsulates the mirrored
packets in a VLAN tag. That includes the case that the mirrored traffic
is already VLAN-tagged--in that case the monitor traffic will be
double-tagged, just like in the software path.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 64 ++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index cd9071ee19ad..d90582ee478f 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -235,6 +235,14 @@ mlxsw_sp_span_entry_bridge(const struct net_device *br_dev,
return dev;
}
+static struct net_device *
+mlxsw_sp_span_entry_vlan(const struct net_device *vlan_dev,
+ u16 *p_vid)
+{
+ *p_vid = vlan_dev_vlan_id(vlan_dev);
+ return vlan_dev_real_dev(vlan_dev);
+}
+
static __maybe_unused int
mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
union mlxsw_sp_l3addr saddr,
@@ -477,6 +485,61 @@ struct mlxsw_sp_span_entry_ops mlxsw_sp_span_entry_ops_gretap6 = {
};
#endif
+static bool
+mlxsw_sp_span_vlan_can_handle(const struct net_device *dev)
+{
+ return is_vlan_dev(dev) &&
+ mlxsw_sp_port_dev_check(vlan_dev_real_dev(dev));
+}
+
+static int
+mlxsw_sp_span_entry_vlan_parms(const struct net_device *to_dev,
+ struct mlxsw_sp_span_parms *sparmsp)
+{
+ struct net_device *real_dev;
+ u16 vid;
+
+ if (!(to_dev->flags & IFF_UP))
+ return mlxsw_sp_span_entry_unoffloadable(sparmsp);
+
+ real_dev = mlxsw_sp_span_entry_vlan(to_dev, &vid);
+ sparmsp->dest_port = netdev_priv(real_dev);
+ sparmsp->vid = vid;
+ return 0;
+}
+
+static int
+mlxsw_sp_span_entry_vlan_configure(struct mlxsw_sp_span_entry *span_entry,
+ struct mlxsw_sp_span_parms sparms)
+{
+ struct mlxsw_sp_port *dest_port = sparms.dest_port;
+ struct mlxsw_sp *mlxsw_sp = dest_port->mlxsw_sp;
+ u8 local_port = dest_port->local_port;
+ char mpat_pl[MLXSW_REG_MPAT_LEN];
+ int pa_id = span_entry->id;
+
+ mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
+ MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH);
+ mlxsw_reg_mpat_eth_rspan_pack(mpat_pl, sparms.vid);
+
+ return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpat), mpat_pl);
+}
+
+static void
+mlxsw_sp_span_entry_vlan_deconfigure(struct mlxsw_sp_span_entry *span_entry)
+{
+ mlxsw_sp_span_entry_deconfigure_common(span_entry,
+ MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH);
+}
+
+static const
+struct mlxsw_sp_span_entry_ops mlxsw_sp_span_entry_ops_vlan = {
+ .can_handle = mlxsw_sp_span_vlan_can_handle,
+ .parms = mlxsw_sp_span_entry_vlan_parms,
+ .configure = mlxsw_sp_span_entry_vlan_configure,
+ .deconfigure = mlxsw_sp_span_entry_vlan_deconfigure,
+};
+
static const
struct mlxsw_sp_span_entry_ops *const mlxsw_sp_span_entry_types[] = {
&mlxsw_sp_span_entry_ops_phys,
@@ -486,6 +549,7 @@ struct mlxsw_sp_span_entry_ops *const mlxsw_sp_span_entry_types[] = {
#if IS_ENABLED(CONFIG_IPV6_GRE)
&mlxsw_sp_span_entry_ops_gretap6,
#endif
+ &mlxsw_sp_span_entry_ops_vlan,
};
static int
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 2/4] mlxsw: reg: Add MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH
From: Ido Schimmel @ 2018-05-10 10:13 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, stephen, nikolay, mlxsw, Ido Schimmel
In-Reply-To: <20180510101306.4891-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Add MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH to support VLAN-encapsulated
port mirroring.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h b/drivers/net/ethernet/mellanox/mlxsw/reg.h
index 6218231e379e..3f4d7e22cece 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -6833,6 +6833,12 @@ enum mlxsw_reg_mpat_span_type {
*/
MLXSW_REG_MPAT_SPAN_TYPE_LOCAL_ETH = 0x0,
+ /* Remote SPAN Ethernet VLAN.
+ * The packet is forwarded to the monitoring port on the monitoring
+ * VLAN.
+ */
+ MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH = 0x1,
+
/* Encapsulated Remote SPAN Ethernet L3 GRE.
* The packet is encapsulated with GRE header.
*/
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 1/4] net: bridge: Allow bridge master in br_vlan_get_info()
From: Ido Schimmel @ 2018-05-10 10:13 UTC (permalink / raw)
To: netdev, bridge; +Cc: Ido Schimmel, mlxsw, nikolay, jiri, petrm, davem
In-Reply-To: <20180510101306.4891-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Mirroring offload in mlxsw needs to check that a given VLAN is allowed
to ingress the bridge device. br_vlan_get_info() is the function that is
used for this, however currently it only supports bridge port devices.
Extend it to support bridge masters as well.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
net/bridge/br_vlan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index df37a5137c25..dc832c0934c6 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -1176,6 +1176,8 @@ int br_vlan_get_info(const struct net_device *dev, u16 vid,
p = br_port_get_check_rtnl(dev);
if (p)
vg = nbp_vlan_group(p);
+ else if (netif_is_bridge_master(dev))
+ vg = br_vlan_group(netdev_priv(dev));
else
return -EINVAL;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 0/4] mlxsw: Support VLAN devices in mirroring offloads
From: Ido Schimmel @ 2018-05-10 10:13 UTC (permalink / raw)
To: netdev, bridge; +Cc: Ido Schimmel, mlxsw, nikolay, jiri, petrm, davem
Petr says:
When offloading "tc action mirred mirror", there are several scenarios
where VLAN devices can show up, that mlxsw can offload on Spectrum
machines.
I) A direct mirror to a VLAN device on top of a front-panel port device
(commonly referred to as "RSPAN")
II) VLAN device in egress path of a packet when resolving a mirror to
gretap or ip6gretap netdevice.
Specifically in the latter case, the following are the cases that can be
offloaded:
IIa) VLAN device directly above a physical device.
IIb) A VLAN-unaware bridge where the egress device is as in IIa.
IIc) VLAN device on top of a VLAN-aware bridge where the egress device
is a physical device.
This patch set implements all the above cases.
First, in patch #1, br_vlan_get_info() is extended to allow bridge
master argument.
Case I is then implemented in patches #2 and #3, case II in patch #4.
Note that handling of VLAN protocol is not included. In case I, mirrored
packets may end up being double-tagged, and it might be reasonable for
the outer tag to be an 802.1ad. However, the protocol type configuration
would have to be put on the same VLAN netdevice that represents normal
VLAN traffic, and mlxsw currently ignores this setting in that case. Thus
this support was left out and the encapsulation always uses 802.1q
protocol.
Petr Machata (4):
net: bridge: Allow bridge master in br_vlan_get_info()
mlxsw: reg: Add MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH
mlxsw: spectrum_span: Support mirror-to-VLAN
mlxsw: spectrum_span: Support VLAN under mirror-to-gretap
drivers/net/ethernet/mellanox/mlxsw/reg.h | 6 ++
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 91 ++++++++++++++++++++--
net/bridge/br_vlan.c | 2 +
3 files changed, 91 insertions(+), 8 deletions(-)
--
2.14.3
^ permalink raw reply
* Re: [PATCH net-next] net/core: delete the no need variable description in devlink_resource_register() comment
From: Sun Lianwen @ 2018-05-10 10:10 UTC (permalink / raw)
To: sergei.shtylyov, davem; +Cc: netdev
In-Reply-To: <858a4f1d-4c15-7495-e7f1-2cbf5f4b110a@cogentembedded.com>
Hi
On 05/10/2018 05:52 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 5/10/2018 6:28 AM, Sun Lianwen wrote:
>
>> The variable "top_hierarchy" and "reload_required" is not existence in
>
> Don't exist, you mean?
my statement maybe not right. I mean is that the parameter of
devlink_resource_register( ) don't have "top_hierarchy" and "reload_required"
3173int devlink_resource_register(struct devlink *devlink,
3174 const char *resource_name,
3175 u64 resource_size,
3176 u64 resource_id,
3177 u64 parent_resource_id,
3178 const struct devlink_resource_size_params *size_params)
>
>> devlink_resource_register()
>>
>> Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
> [...]
>
> MBR, Sergei
>
>
>
Thanks,
Sun Lianwen
^ permalink raw reply
* Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto
From: Peter Zijlstra @ 2018-05-10 10:06 UTC (permalink / raw)
To: Yonghong Song
Cc: mingo, torvalds, ast, daniel, linux-kernel, x86, netdev,
kernel-team, Thomas Gleixner
In-Reply-To: <20180504033119.2130788-1-yhs@fb.com>
On Thu, May 03, 2018 at 08:31:19PM -0700, Yonghong Song wrote:
> This approach is preferred since the already deployed bcc scripts, or
> any other bpf applicaitons utilizing LLVM JIT compilation functionality,
> will continue work with the new kernel without re-compilation and
> re-deployment.
So I really hate this and would much rather see the BPF build
environment changed. It not consistenyly having __BPF__ defined really
smells like a bug on your end.
Sometimes you just need to update tools... Is it really too hard to do
-D__BPF__ in the bpf build process that we need to mollest the kernel
for it?
> Note that this is a hack in the kernel to workaround bpf compilation issue.
> The hack will be removed once clang starts to support asm goto.
Note that that ^^ already mandates people re-deploy their bpf tools, so
why is llvm supporting asm-goto a better point to re-deploy than fixing
a consistent __BPF__ define for the bpf build environment?
> diff --git a/Makefile b/Makefile
> index 83b6c54..cfd8759 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -504,6 +504,7 @@ export RETPOLINE_CFLAGS
> ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) $(KBUILD_CFLAGS)), y)
> CC_HAVE_ASM_GOTO := 1
> KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
> + KBUILD_CFLAGS += -D__NO_CLANG_BPF_HACK
> KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
> endif
I really think this is the wrong thing to do; but if the x86 maintainers
are willing to take this, I'll grudingly shut up.
Ingo, Thomas?
> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
> index b27da96..42edd5d 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -140,6 +140,8 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
>
> #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
>
> +/* this macro is a temporary hack for bpf until clang gains asm-goto support */
> +#ifdef __NO_CLANG_BPF_HACK
> /*
> * Static testing of CPU features. Used the same as boot_cpu_has().
> * These will statically patch the target code for additional
> @@ -195,6 +197,9 @@ static __always_inline __pure bool _static_cpu_has(u16 bit)
> boot_cpu_has(bit) : \
> _static_cpu_has(bit) \
> )
> +#else
> +#define static_cpu_has(bit) boot_cpu_has(bit)
> +#endif
>
> #define cpu_has_bug(c, bit) cpu_has(c, (bit))
> #define set_cpu_bug(c, bit) set_cpu_cap(c, (bit))
> --
> 2.9.5
>
^ 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