* 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
* Re: [PATCH net-next] net/core: delete the no need variable description in devlink_resource_register() comment
From: Sergei Shtylyov @ 2018-05-10 9:52 UTC (permalink / raw)
To: Sun Lianwen, davem; +Cc: netdev
In-Reply-To: <20180510032800.5450-1-sunlw.fnst@cn.fujitsu.com>
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?
> devlink_resource_register()
>
> Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: kernel BUG at net/core/skbuff.c:LINE! (3)
From: Dmitry Vyukov @ 2018-05-10 9:51 UTC (permalink / raw)
To: Xin Long, William Tu, mvohra
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
In-Reply-To: <CADvbK_d9Z3OsHnLc2mg-3e=0t6sVFnEVXoDah3nWJrFSyaq+5w@mail.gmail.com>
On Sat, Feb 10, 2018 at 12:17 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Fri, Feb 2, 2018 at 3:21 AM, syzbot
> <syzbot+b2bf2652983d23734c5c@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot hit the following crash on net-next commit
>> b2fe5fa68642860e7de76167c3111623aa0d5de1 (Wed Jan 31 22:31:10 2018 +0000)
>> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+b2bf2652983d23734c5c@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> skbuff: skb_over_panic: text:000000004b89f3be len:66136 put:66124
>> head:00000000f255561a data:00000000ccb55e52 tail:0x10310 end:0x6c0
>> dev:<NULL>
> From the raw log, it should be a data chunk.
> But I couldn't see how len:66136 happened?
> considering that frag_point is always smaller than SCTP_MAX_CHUNK_LEN.
William, Meenakshi,
This crash was bisected to:
commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
Author: William Tu <u9012063@gmail.com>
Date: Tue Aug 22 09:40:28 2017 -0700
gre: introduce native tunnel support for ERSPAN
bisection log:
https://gist.githubusercontent.com/dvyukov/a9661d43b2b519b91540f7466dbc32c1/raw/8df343224177933c8c398be126bb82be99aa0b4b/gistfile1.txt
>> ------------[ cut here ]------------
>> kernel BUG at net/core/skbuff.c:104!
>> invalid opcode: 0000 [#1] SMP KASAN
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 19738 Comm: syz-executor3 Not tainted 4.15.0+ #219
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100
>> RSP: 0018:ffff8801c1a6e4e8 EFLAGS: 00010286
>> RAX: 000000000000008f RBX: ffff8801d0090000 RCX: 0000000000000000
>> RDX: 000000000000008f RSI: ffffc90003d53000 RDI: ffffed003834dc91
>> RBP: ffff8801c1a6e550 R08: 1ffff1003834dc1f R09: 0000000000000000
>> R10: 0000000000000004 R11: 0000000000000000 R12: ffffffff863fe4e0
>> R13: ffffffff85276640 R14: 000000000001024c R15: ffffffff863fdd20
>> FS: 00007f69cd01b700(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000000718008 CR3: 00000001c71c7006 CR4: 00000000001606e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>> skb_over_panic net/core/skbuff.c:109 [inline]
>> skb_put+0x18d/0x1d0 net/core/skbuff.c:1695
>> skb_put_data include/linux/skbuff.h:2049 [inline]
>> sctp_packet_pack net/sctp/output.c:473 [inline]
>> sctp_packet_transmit+0x1180/0x3750 net/sctp/output.c:606
>> sctp_outq_flush+0x121b/0x4060 net/sctp/outqueue.c:1197
>> sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:776
>> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1807 [inline]
>> sctp_side_effects net/sctp/sm_sideeffect.c:1210 [inline]
>> sctp_do_sm+0x4e0/0x6ed0 net/sctp/sm_sideeffect.c:1181
>> sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
>> sctp_sendmsg+0x1894/0x35e0 net/sctp/socket.c:2029
>> inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
>> sock_sendmsg_nosec net/socket.c:630 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:640
>> sock_write_iter+0x31a/0x5d0 net/socket.c:909
>> call_write_iter include/linux/fs.h:1781 [inline]
>> do_iter_readv_writev+0x55c/0x830 fs/read_write.c:653
>> do_iter_write+0x154/0x540 fs/read_write.c:932
>> vfs_writev+0x18a/0x340 fs/read_write.c:977
>> do_writev+0xfc/0x2a0 fs/read_write.c:1012
>> SYSC_writev fs/read_write.c:1085 [inline]
>> SyS_writev+0x27/0x30 fs/read_write.c:1082
>> entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x453299
>> RSP: 002b:00007f69cd01ac58 EFLAGS: 00000212 ORIG_RAX: 0000000000000014
>> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000453299
>> RDX: 0000000000000001 RSI: 0000000020f7ffe0 RDI: 0000000000000013
>> RBP: 00000000000005c5 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f7b18
>> R13: 00000000ffffffff R14: 00007f69cd01b6d4 R15: 0000000000000000
>> Code: 04 01 84 c0 74 04 3c 03 7e 23 8b 8b 80 00 00 00 41 57 48 c7 c7 60 dd
>> 3f 86 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8 c6 d7 25 fd <0f> 0b 4c 89 4d
>> b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 47 53
>> RIP: skb_panic+0x162/0x1f0 net/core/skbuff.c:100 RSP: ffff8801c1a6e4e8
>> ---[ end trace c7cd29819a9b12ab ]---
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [RFC v3 3/5] virtio_ring: add packed ring support
From: Jason Wang @ 2018-05-10 9:49 UTC (permalink / raw)
To: Tiwei Bie; +Cc: mst, virtualization, linux-kernel, netdev, wexu
In-Reply-To: <20180510085601.6mpxf3yvwxnqnk5q@debian>
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.
Thanks
^ permalink raw reply
* [PATCH net] sctp: remove sctp_chunk_put from fail_mark err path in sctp_ulpevent_make_rcvmsg
From: Xin Long @ 2018-05-10 9:34 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Neil Horman, syzkaller
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
^ permalink raw reply related
* Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()
From: Alexey Kodanev @ 2018-05-10 9:28 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley, Richard Haines
Cc: selinux, Eric Paris, linux-security-module, netdev
In-Reply-To: <CAHC9VhRmX+Z+ignXXBrSGyUkpxudO76Fv-6o_My=skh-U8Ccgw@mail.gmail.com>
On 10.05.2018 01:02, Paul Moore wrote:
...
> I just had a better look at this and I believe that Alexey and Stephen
> are right: this is the best option. My apologies for the noise
> earlier. However, while looking at the code I think there are some
> additional necessary changes:
>
> * In the case of an SCTP socket, we should return -EINVAL, just as we
> do with other address families.
Right.
> * While not strictly related to AF_UNSPEC, we really should be passing
> the address family of the sockaddr, and not the socket, to functions
> that need to interpret the bind address/port.
That looks like a correct solution. I guess we need the same fix for
sctp_connectx(), in selinux_socket_connect_helper().
>
> I'm waiting for my kernel to compile so I haven't given this any
> sanity testing, but the patch below is what I think we need ...
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4cafe6a19167..5f30045b2053 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4576,6 +4576,7 @@ static int selinux_socket_post_create(struct socket *sock,
> int family,
> static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, i
> nt addrlen)
> {
> struct sock *sk = sock->sk;
> + struct sk_security_struct *sksec = sk->sk_security;
> u16 family;
> int err;
>
> @@ -4587,13 +4588,13 @@ static int selinux_socket_bind(struct socket *sock, stru
> ct sockaddr *address, in
> family = sk->sk_family;
> if (family == PF_INET || family == PF_INET6) {
> char *addrp;
> - struct sk_security_struct *sksec = sk->sk_security;
> struct common_audit_data ad;
> struct lsm_network_audit net = {0,};
> struct sockaddr_in *addr4 = NULL;
> struct sockaddr_in6 *addr6 = NULL;
> unsigned short snum;
> u32 sid, node_perm;
> + u16 family_sa = address->sa_family;
>
> /*
> * sctp_bindx(3) calls via selinux_sctp_bind_connect()
> @@ -4601,11 +4602,19 @@ static int selinux_socket_bind(struct socket *sock, stru
> ct sockaddr *address, in
> * need to check address->sa_family as it is possible to have
> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
> */
> - switch (address->sa_family) {
> + switch (family_sa) {
> + case AF_UNSPEC:
> case AF_INET:
> if (addrlen < sizeof(struct sockaddr_in))
> return -EINVAL;
> addr4 = (struct sockaddr_in *)address;
> + if (family_sa == AF_UNSPEC) {
> + /* see "__inet_bind()", we only want to allow
> + * AF_UNSPEC if the address is INADDR_ANY */
> + if (addr4->sin_addr.s_addr != htonl(INADDR_ANY))
> + goto err_af;
> + family_sa = AF_INET;
> + }
> snum = ntohs(addr4->sin_port);
> addrp = (char *)&addr4->sin_addr.s_addr;
> break;
> @@ -4617,15 +4626,14 @@ static int selinux_socket_bind(struct socket *sock, stru
> ct sockaddr *address, in
> addrp = (char *)&addr6->sin6_addr.s6_addr;
> break;
> default:
> - /* Note that SCTP services expect -EINVAL, whereas
> - * others expect -EAFNOSUPPORT.
> - */
> - if (sksec->sclass == SECCLASS_SCTP_SOCKET)
> - return -EINVAL;
> - else
> - return -EAFNOSUPPORT;
> + goto err_af;
> }
>
> + ad.type = LSM_AUDIT_DATA_NET;
> + ad.u.net = &net;
> + ad.u.net->sport = htons(snum);
> + ad.u.net->family = family_sa;
> +
May be we could move setting ad.u.net->v{4|6}info.saddr here as well?
Will send a v2 of this patch so that SCTP socket returns EINVAL with
AF_UNSPEC. Should I prepare a patch with correcting 'ad.u.net->family'
and sel_netnode_sid()?
Thanks,
Alexey
> if (snum) {
> int low, high;
>
> @@ -4637,10 +4645,6 @@ static int selinux_socket_bind(struct socket *sock, struc
> t sockaddr *address, in
> snum, &sid);
> if (err)
> goto out;
> - ad.type = LSM_AUDIT_DATA_NET;
> - ad.u.net = &net;
> - ad.u.net->sport = htons(snum);
> - ad.u.net->family = family;
> err = avc_has_perm(&selinux_state,
> sksec->sid, sid,
> sksec->sclass,
> @@ -4672,16 +4676,11 @@ static int selinux_socket_bind(struct socket *sock, stru
> ct sockaddr *address, in
> break;
> }
>
> - err = sel_netnode_sid(addrp, family, &sid);
> + err = sel_netnode_sid(addrp, family_sa, &sid);
> if (err)
> goto out;
>
> - ad.type = LSM_AUDIT_DATA_NET;
> - ad.u.net = &net;
> - ad.u.net->sport = htons(snum);
> - ad.u.net->family = family;
> -
> - if (address->sa_family == AF_INET)
> + if (family_sa == AF_INET)
> ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
> else
> ad.u.net->v6info.saddr = addr6->sin6_addr;
> @@ -4694,6 +4693,12 @@ static int selinux_socket_bind(struct socket *sock, struc
> t sockaddr *address, in
> }
> out:
> return err;
> +err_af:
> + /* Note that SCTP services expect -EINVAL, others -EAFNOSUPPORT. */
> + if (sksec->sclass == SECCLASS_SCTP_SOCKET)
> + return -EINVAL;
> + else
> + return -EAFNOSUPPORT;
> }
>
> /* This supports connect(2) and SCTP connect services such as sctp_connectx(3)
>
^ permalink raw reply
* Re: [bpf-next PATCH 1/4] bpf: devmap introduce dev_map_enqueue
From: kbuild test robot @ 2018-05-10 9:10 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: kbuild-all, netdev, Daniel Borkmann, Alexei Starovoitov,
Jesper Dangaard Brouer, Christoph Hellwig, BjörnTöpel,
Magnus Karlsson
In-Reply-To: <152587157974.20423.10791157575158535841.stgit@firesoul>
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
Hi Jesper,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Jesper-Dangaard-Brouer/xdp-introduce-bulking-for-ndo_xdp_xmit-API/20180510-134105
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-randconfig-x014-201818 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from kernel/sysctl.c:67:0:
>> include/linux/bpf.h:577:28: warning: 'struct bpf_dtab_netdev' declared inside parameter list will not be visible outside of this definition or declaration
int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp)
^~~~~~~~~~~~~~~
vim +577 include/linux/bpf.h
574
575 struct xdp_buff;
576 static inline
> 577 int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp)
578 {
579 return 0;
580 }
581
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26956 bytes --]
^ permalink raw reply
* Re: [bpf-next PATCH 1/4] bpf: devmap introduce dev_map_enqueue
From: kbuild test robot @ 2018-05-10 9:10 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: kbuild-all, netdev, Daniel Borkmann, Alexei Starovoitov,
Jesper Dangaard Brouer, Christoph Hellwig, BjörnTöpel,
Magnus Karlsson
In-Reply-To: <152587157974.20423.10791157575158535841.stgit@firesoul>
[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]
Hi Jesper,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Jesper-Dangaard-Brouer/xdp-introduce-bulking-for-ndo_xdp_xmit-API/20180510-134105
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from net/core/filter.c:52:0:
include/linux/bpf.h:577:28: warning: 'struct bpf_dtab_netdev' declared inside parameter list will not be visible outside of this definition or declaration
int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp)
^~~~~~~~~~~~~~~
net/core/filter.c: In function '__bpf_tx_xdp_map':
>> net/core/filter.c:3025:25: error: passing argument 1 of 'dev_map_enqueue' from incompatible pointer type [-Werror=incompatible-pointer-types]
err = dev_map_enqueue(dst, xdp);
^~~
In file included from net/core/filter.c:52:0:
include/linux/bpf.h:577:5: note: expected 'struct bpf_dtab_netdev *' but argument is of type 'struct bpf_dtab_netdev *'
int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp)
^~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/dev_map_enqueue +3025 net/core/filter.c
3013
3014 static int __bpf_tx_xdp_map(struct net_device *dev_rx, void *fwd,
3015 struct bpf_map *map,
3016 struct xdp_buff *xdp,
3017 u32 index)
3018 {
3019 int err;
3020
3021 switch (map->map_type) {
3022 case BPF_MAP_TYPE_DEVMAP: {
3023 struct bpf_dtab_netdev *dst = fwd;
3024
> 3025 err = dev_map_enqueue(dst, xdp);
3026 if (err)
3027 return err;
3028 __dev_map_insert_ctx(map, index);
3029 break;
3030 }
3031 case BPF_MAP_TYPE_CPUMAP: {
3032 struct bpf_cpu_map_entry *rcpu = fwd;
3033
3034 err = cpu_map_enqueue(rcpu, xdp, dev_rx);
3035 if (err)
3036 return err;
3037 __cpu_map_insert_ctx(map, index);
3038 break;
3039 }
3040 case BPF_MAP_TYPE_XSKMAP: {
3041 struct xdp_sock *xs = fwd;
3042
3043 err = __xsk_map_redirect(map, xdp, xs);
3044 return err;
3045 }
3046 default:
3047 break;
3048 }
3049 return 0;
3050 }
3051
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30404 bytes --]
^ 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