* Re: [PATCH] net-ipv6: on device mtu change do not add mtu to mtu-less routes
From: Hannes Frederic Sowa @ 2016-11-07 19:28 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller
Cc: netdev, Eric Dumazet
In-Reply-To: <1478296314-32396-1-git-send-email-zenczykowski@gmail.com>
On 04.11.2016 22:51, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> Routes can specify an mtu explicitly or inherit the mtu from
> the underlying device - this inheritance is implemented in
> dst->ops->mtu handlers ip6_mtu() and ip6_blackhole_mtu().
>
> Currently changing the mtu of a device adds mtu explicitly
> to routes using that device.
>
> ie.
> # ip link set dev lo mtu 65536
> # ip -6 route add local 2000::1 dev lo
> # ip -6 route get 2000::1
> local 2000::1 dev lo table local src ... metric 1024 pref medium
>
> # ip link set dev lo mtu 65535
> # ip -6 route get 2000::1
> local 2000::1 dev lo table local src ... metric 1024 mtu 65535 pref medium
>
> # ip link set dev lo mtu 65536
> # ip -6 route get 2000::1
> local 2000::1 dev lo table local src ... metric 1024 mtu 65536 pref medium
>
> # ip -6 route del local 2000::1
>
> After this patch the route entry no longer changes unless it already has an mtu.
> There is no need: this inheritance is already done in ip6_mtu()
>
> # ip link set dev lo mtu 65536
> # ip -6 route add local 2000::1 dev lo
> # ip -6 route add local 2000::2 dev lo mtu 2000
> # ip -6 route get 2000::1; ip -6 route get 2000::2
> local 2000::1 dev lo table local src ... metric 1024 pref medium
> local 2000::2 dev lo table local src ... metric 1024 mtu 2000 pref medium
>
> # ip link set dev lo mtu 65535
> # ip -6 route get 2000::1; ip -6 route get 2000::2
> local 2000::1 dev lo table local src ... metric 1024 pref medium
> local 2000::2 dev lo table local src ... metric 1024 mtu 2000 pref medium
>
> # ip link set dev lo mtu 1501
> # ip -6 route get 2000::1; ip -6 route get 2000::2
> local 2000::1 dev lo table local src ... metric 1024 pref medium
> local 2000::2 dev lo table local src ... metric 1024 mtu 1501 pref medium
>
> # ip link set dev lo mtu 65536
> # ip -6 route get 2000::1; ip -6 route get 2000::2
> local 2000::1 dev lo table local src ... metric 1024 pref medium
> local 2000::2 dev lo table local src ... metric 1024 mtu 65536 pref medium
>
> # ip -6 route del local 2000::1
> # ip -6 route del local 2000::2
>
> This is desirable because changing device mtu and then resetting it
> to the previous value shouldn't change the user visible routing table.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> CC: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv6/route.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 947ed1ded026..fa90d14302f7 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2758,6 +2758,7 @@ static int rt6_mtu_change_route(struct rt6_info *rt, void *p_arg)
> PMTU discouvery.
> */
> if (rt->dst.dev == arg->dev &&
> + dst_metric_raw(&rt->dst, RTAX_MTU) &&
> !dst_metric_locked(&rt->dst, RTAX_MTU)) {
> if (rt->rt6i_flags & RTF_CACHE) {
> /* For RTF_CACHE with rt6i_pmtu == 0
>
Yep, that makes sense.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* net/tcp: warning in tcp_recvmsg
From: Andrey Konovalov @ 2016-11-07 19:15 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML
Cc: Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller
Hi,
I've got the following error report while running the syzkaller fuzzer:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 9957 at net/ipv4/tcp.c:1766
tcp_recvmsg+0x19d7/0x26e0 net/ipv4/tcp.c:1765
Modules linked in:
CPU: 1 PID: 9957 Comm: syz-executor Not tainted 4.9.0-rc4+ #352
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff880065bd7788 ffffffff81b46a64 0000000000000000 0000000000000000
ffffffff8445f8e0 0000000000000000 ffff880065bd77d0 ffffffff81111387
ffff880068414980 00000000000006e6 ffffffff8445f8e0 00000000000006e6
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46a64>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff81111387>] __warn+0x1a7/0x1f0 kernel/panic.c:550
[<ffffffff8111159c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
[<ffffffff830a95b7>] tcp_recvmsg+0x19d7/0x26e0 net/ipv4/tcp.c:1765
[<ffffffff83171e28>] inet_recvmsg+0x308/0x4b0 net/ipv4/af_inet.c:765
[< inline >] sock_recvmsg_nosec net/socket.c:708
[<ffffffff82b6fb29>] sock_recvmsg+0xd9/0x110 net/socket.c:715
[<ffffffff82b6fda7>] sock_read_iter+0x247/0x360 net/socket.c:792
[<ffffffff8151e2db>] do_iter_readv_writev+0x2bb/0x3f0 fs/read_write.c:695
[<ffffffff81520141>] do_readv_writev+0x431/0x730 fs/read_write.c:872
[<ffffffff815204cc>] vfs_readv+0x8c/0xc0 fs/read_write.c:898
[<ffffffff815205e1>] do_readv+0xe1/0x240 fs/read_write.c:924
[< inline >] SYSC_readv fs/read_write.c:1011
[<ffffffff815238b7>] SyS_readv+0x27/0x30 fs/read_write.c:1008
[<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
---[ end trace 8efae7c5dcb2bd76 ]---
On commit bc33b0ca11e3df467777a4fa7639ba488c9d4911 (Nov 5).
Thanks!
^ permalink raw reply
* [PATCH net-next] net-gro: avoid reorders
From: Eric Dumazet @ 2016-11-07 19:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Receiving a GSO packet in dev_gro_receive() is not uncommon
in stacked devices, or devices partially implementing LRO/GRO
like bnx2x. GRO is implementing the aggregation the device
was not able to do itself.
Current code causes reorders, like in following case :
For a given flow where sender sent 3 packets P1,P2,P3,P4
Receiver might receive P1 as a single packet, stored in GRO engine.
Then P2-P4 are received as a single GSO packet, immediately given to
upper stack, while P1 is held in GRO engine.
This patch will make sure P1 is given to upper stack, then P2-P4
immediately after.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index f23e28668f32..b77cde68967c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4482,7 +4482,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
if (!(skb->dev->features & NETIF_F_GRO))
goto normal;
- if (skb_is_gso(skb) || skb_has_frag_list(skb) || skb->csum_bad)
+ if (skb->csum_bad)
goto normal;
gro_list_prepare(napi, skb);
@@ -4495,7 +4495,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
skb_set_network_header(skb, skb_gro_offset(skb));
skb_reset_mac_len(skb);
NAPI_GRO_CB(skb)->same_flow = 0;
- NAPI_GRO_CB(skb)->flush = 0;
+ NAPI_GRO_CB(skb)->flush = skb_is_gso(skb) || skb_has_frag_list(skb);
NAPI_GRO_CB(skb)->free = 0;
NAPI_GRO_CB(skb)->encap_mark = 0;
NAPI_GRO_CB(skb)->recursion_counter = 0;
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH] igb: drop field "tail" of struct igb_ring
From: Alexander Duyck @ 2016-11-07 18:49 UTC (permalink / raw)
To: Cao jin
Cc: linux-kernel@vger.kernel.org, Netdev,
Izumi, Taku/泉 拓, intel-wired-lan
In-Reply-To: <1478522697-4773-1-git-send-email-caoj.fnst@cn.fujitsu.com>
On Mon, Nov 7, 2016 at 4:44 AM, Cao jin <caoj.fnst@cn.fujitsu.com> wrote:
> Under certain condition, I find guest will oops on writel() in
> igb_configure_tx_ring(), because hw->hw_address is NULL. While other
> register access won't oops kernel because they use wr32/rd32 which have
> a defense against NULL pointer. The oops message are as following:
>
> [ 141.225449] pcieport 0000:00:1c.0: AER: Multiple Uncorrected (Fatal)
> error received: id=0101
> [ 141.225523] igb 0000:01:00.1: PCIe Bus Error: severity=Uncorrected
> (Fatal), type=Unaccessible, id=0101(Unregistered Agent ID)
> [ 141.299442] igb 0000:01:00.1: broadcast error_detected message
> [ 141.300539] igb 0000:01:00.0 enp1s0f0: PCIe link lost, device now
> detached
> [ 141.351019] igb 0000:01:00.1 enp1s0f1: PCIe link lost, device now
> detached
> [ 143.465904] pcieport 0000:00:1c.0: Root Port link has been reset
> [ 143.465994] igb 0000:01:00.1: broadcast slot_reset message
> [ 143.466039] igb 0000:01:00.0: enabling device (0000 -> 0002)
> [ 144.389078] igb 0000:01:00.1: enabling device (0000 -> 0002)
> [ 145.312078] igb 0000:01:00.1: broadcast resume message
> [ 145.322211] BUG: unable to handle kernel paging request at
> 0000000000003818
> [ 145.361275] IP: [<ffffffffa02fd38d>] igb_configure_tx_ring+0x14d/0x280 [igb]
> [ 145.438007] Oops: 0002 [#1] SMP
>
> On the other hand, commit 238ac817 does some optimization which
> dropped the field "head". So I think it is time to drop "tail" as well.
There is a bug here, but removing tail isn't the fix.
> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 1 -
> drivers/net/ethernet/intel/igb/igb_main.c | 16 +++++++++-------
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
> index d11093d..0df06bc 100644
> --- a/drivers/net/ethernet/intel/igb/igb.h
> +++ b/drivers/net/ethernet/intel/igb/igb.h
> @@ -247,7 +247,6 @@ struct igb_ring {
> };
> void *desc; /* descriptor ring memory */
> unsigned long flags; /* ring specific flags */
> - void __iomem *tail; /* pointer to ring tail register */
> dma_addr_t dma; /* phys address of the ring */
> unsigned int size; /* length of desc. ring in bytes */
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> index edc9a6a..e177d0e 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -3390,9 +3390,8 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
> tdba & 0x00000000ffffffffULL);
> wr32(E1000_TDBAH(reg_idx), tdba >> 32);
>
> - ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
This line is where the bug is. This should be adapter->io_addr, not
hw->hw_addr.
> wr32(E1000_TDH(reg_idx), 0);
> - writel(0, ring->tail);
> + wr32(E1000_TDT(reg_idx), 0);
>
> txdctl |= IGB_TX_PTHRESH;
> txdctl |= IGB_TX_HTHRESH << 8;
> @@ -3729,9 +3728,8 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> ring->count * sizeof(union e1000_adv_rx_desc));
>
> /* initialize head and tail */
> - ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
Same thing here. It looks like the wrong values where used.
> wr32(E1000_RDH(reg_idx), 0);
> - writel(0, ring->tail);
> + wr32(E1000_RDT(reg_idx), 0);
>
> /* set descriptor configuration */
Would you prefer to submit the patch for this or should I? Basically
all you need to do is change the two lines where ring->tail is
populated so that you use adapter->io_addr instead of hw->hw_addr.
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH 7/8] tools lib bpf: fix maps resolution
From: Eric Leblond @ 2016-11-07 18:40 UTC (permalink / raw)
To: Wangnan (F), netdev; +Cc: linux-kernel, ast, Daniel Borkmann, Joe Stringer
In-Reply-To: <5820C6BE.9080300@huawei.com>
Hi,
On Tue, 2016-11-08 at 02:23 +0800, Wangnan (F) wrote:
> Hi Eric,
>
> Are you still working in this patch set?
Sorry to lag on this, I've been taken by a series of other projects. I
did not yet reworked it yet but I was planning to do a bit on it this
week.
>
> Now I know why maps section is not a simple array
> from a patch set from Joe Stringer:
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg135088.html
>
> So I think this patch is really useful.
>
> Are you going to resend the whole patch set? If not, let me collect
> this patch 7/8 into my local code base and send to Arnaldo
> with my other patches.
If ok with you, I propose that you collect patch 7/8 it you have no
news from me on Friday. If an issue for you, just collect it now and I
will synchronize with updated code when resending my patchset.
BR,
--
Eric Leblond <eric@regit.org>
Blog: https://home.regit.org/
^ permalink raw reply
* Re: [PATCH net] bpf: fix map not being uncharged during map creation failure
From: David Miller @ 2016-11-07 18:23 UTC (permalink / raw)
To: daniel; +Cc: netdev, ast
In-Reply-To: <89c1a3a48ca9940a0fdc1298e11c03c4074a1c59.1478216947.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 4 Nov 2016 00:56:31 +0100
> In map_create(), we first find and create the map, then once that
> suceeded, we charge it to the user's RLIMIT_MEMLOCK, and then fetch
> a new anon fd through anon_inode_getfd(). The problem is, once the
> latter fails f.e. due to RLIMIT_NOFILE limit, then we only destruct
> the map via map->ops->map_free(), but without uncharging the previously
> locked memory first. That means that the user_struct allocation is
> leaked as well as the accounted RLIMIT_MEMLOCK memory not released.
> Make the label names in the fix consistent with bpf_prog_load().
>
> Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 0/2] udp: do fwd memory scheduling on dequeue
From: David Miller @ 2016-11-07 18:24 UTC (permalink / raw)
To: pabeni-H+wXaHxf7aLQT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1478254512.git.pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Fri, 4 Nov 2016 11:28:57 +0100
> After commit 850cbaddb52d ("udp: use it's own memory accounting schema"),
> the udp code needs to acquire twice the receive queue spinlock on dequeue.
>
> This patch series remove the need for the second lock at skb free time,
> moving the udp memory scheduling inside the dequeue operation; the skb
> destructor field is not used anymore and an additional sk argument is added
> to ip_cmsg_recv_offset() to cope with null skb->sk after dequeue.
>
> Many thanks to Eric Dumazed for suggesting pretty all much the above.
Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 7/8] tools lib bpf: fix maps resolution
From: Wangnan (F) @ 2016-11-07 18:23 UTC (permalink / raw)
To: Eric Leblond, netdev; +Cc: linux-kernel, ast, Daniel Borkmann, Joe Stringer
In-Reply-To: <20161016211834.11732-8-eric@regit.org>
Hi Eric,
Are you still working in this patch set?
Now I know why maps section is not a simple array
from a patch set from Joe Stringer:
https://www.mail-archive.com/netdev@vger.kernel.org/msg135088.html
So I think this patch is really useful.
Are you going to resend the whole patch set? If not, let me collect
this patch 7/8 into my local code base and send to Arnaldo
with my other patches.
Thank you.
On 2016/10/17 5:18, Eric Leblond wrote:
> It is not correct to assimilate the elf data of the maps section
> to an array of map definition. In fact the sizes differ. The
> offset provided in the symbol section has to be used instead.
>
> This patch fixes a bug causing a elf with two maps not to load
> correctly.
>
> Signed-off-by: Eric Leblond <eric@regit.org>
> ---
> tools/lib/bpf/libbpf.c | 50 +++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 1fe4532..f72628b 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -186,6 +186,7 @@ struct bpf_program {
> struct bpf_map {
> int fd;
> char *name;
> + size_t offset;
> struct bpf_map_def def;
> void *priv;
> bpf_map_clear_priv_t clear_priv;
> @@ -529,13 +530,6 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
>
> pr_debug("maps in %s: %zd bytes\n", obj->path, size);
>
> - obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
> - if (!obj->maps) {
> - pr_warning("alloc maps for object failed\n");
> - return -ENOMEM;
> - }
> - obj->nr_maps = nr_maps;
> -
> for (i = 0; i < nr_maps; i++) {
> struct bpf_map_def *def = &obj->maps[i].def;
>
> @@ -547,23 +541,42 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
> obj->maps[i].fd = -1;
>
> /* Save map definition into obj->maps */
> - *def = ((struct bpf_map_def *)data)[i];
> + *def = *(struct bpf_map_def *)(data + obj->maps[i].offset);
> }
> return 0;
> }
>
> static int
> -bpf_object__init_maps_name(struct bpf_object *obj)
> +bpf_object__init_maps_symbol(struct bpf_object *obj)
> {
> int i;
> + int nr_maps = 0;
> Elf_Data *symbols = obj->efile.symbols;
> + size_t map_idx = 0;
>
> if (!symbols || obj->efile.maps_shndx < 0)
> return -EINVAL;
>
> + /* get the number of maps */
> + for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
> + GElf_Sym sym;
> +
> + if (!gelf_getsym(symbols, i, &sym))
> + continue;
> + if (sym.st_shndx != obj->efile.maps_shndx)
> + continue;
> + nr_maps++;
> + }
> +
> + obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
> + if (!obj->maps) {
> + pr_warning("alloc maps for object failed\n");
> + return -ENOMEM;
> + }
> + obj->nr_maps = nr_maps;
> +
> for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
> GElf_Sym sym;
> - size_t map_idx;
> const char *map_name;
>
> if (!gelf_getsym(symbols, i, &sym))
> @@ -574,12 +587,12 @@ bpf_object__init_maps_name(struct bpf_object *obj)
> map_name = elf_strptr(obj->efile.elf,
> obj->efile.strtabidx,
> sym.st_name);
> - map_idx = sym.st_value / sizeof(struct bpf_map_def);
> if (map_idx >= obj->nr_maps) {
> pr_warning("index of map \"%s\" is buggy: %zu > %zu\n",
> map_name, map_idx, obj->nr_maps);
> continue;
> }
> + obj->maps[map_idx].offset = sym.st_value;
> obj->maps[map_idx].name = strdup(map_name);
> if (!obj->maps[map_idx].name) {
> pr_warning("failed to alloc map name\n");
> @@ -587,6 +600,7 @@ bpf_object__init_maps_name(struct bpf_object *obj)
> }
> pr_debug("map %zu is \"%s\"\n", map_idx,
> obj->maps[map_idx].name);
> + map_idx++;
> }
> return 0;
> }
> @@ -647,8 +661,6 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
> data->d_buf,
> data->d_size);
> else if (strcmp(name, "maps") == 0) {
> - err = bpf_object__init_maps(obj, data->d_buf,
> - data->d_size);
> obj->efile.maps_shndx = idx;
> } else if (sh.sh_type == SHT_SYMTAB) {
> if (obj->efile.symbols) {
> @@ -698,8 +710,16 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
> pr_warning("Corrupted ELF file: index of strtab invalid\n");
> return LIBBPF_ERRNO__FORMAT;
> }
> - if (obj->efile.maps_shndx >= 0)
> - err = bpf_object__init_maps_name(obj);
> + if (obj->efile.maps_shndx >= 0) {
> + Elf_Data *data;
> + err = bpf_object__init_maps_symbol(obj);
> + if (err)
> + goto out;
> +
> + scn = elf_getscn(elf, obj->efile.maps_shndx);
> + data = elf_getdata(scn, 0);
> + err = bpf_object__init_maps(obj, data->d_buf, data->d_size);
> + }
> out:
> return err;
> }
^ permalink raw reply
* Re: [PATCH net] bpf: fix htab map destruction when extra reserve is in use
From: David Miller @ 2016-11-07 18:21 UTC (permalink / raw)
To: daniel; +Cc: netdev, ast, dvyukov
In-Reply-To: <e8a8cc8011d16169eaf604b78583836ab2246f0e.1478213579.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 4 Nov 2016 00:01:19 +0100
> Commit a6ed3ea65d98 ("bpf: restore behavior of bpf_map_update_elem")
> added an extra per-cpu reserve to the hash table map to restore old
> behaviour from pre prealloc times. When non-prealloc is in use for a
> map, then problem is that once a hash table extra element has been
> linked into the hash-table, and the hash table is destroyed due to
> refcount dropping to zero, then htab_map_free() -> delete_all_elements()
> will walk the whole hash table and drop all elements via htab_elem_free().
> The problem is that the element from the extra reserve is first fed
> to the wrong backend allocator and eventually freed twice.
>
> Fixes: a6ed3ea65d98 ("bpf: restore behavior of bpf_map_update_elem")
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/2] sfc: enable 4-tuple UDP RSS hashing
From: David Miller @ 2016-11-07 18:20 UTC (permalink / raw)
To: ecree; +Cc: netdev, linux-net-drivers
In-Reply-To: <ba5aa0bc-277b-5b47-89f8-fad1010b77f9@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Thu, 3 Nov 2016 22:10:31 +0000
> EF10 based NICs have configurable RSS hash fields, and can be made to take the
> ports into the hash on UDP (they already do so for TCP). This patch series
> enables this, in order to improve spreading of UDP traffic.
What does the chip do with fragmented traffic?
^ permalink raw reply
* Re: [PATCH net] sctp: assign assoc_id earlier in __sctp_connect
From: David Miller @ 2016-11-07 18:19 UTC (permalink / raw)
To: marcelo.leitner
Cc: netdev, linux-sctp, vyasevich, nhorman, syzkaller, kcc, glider,
edumazet, dvyukov, andreyknvl
In-Reply-To: <9df38dcd0323ad92386eb6851a60dc128dd00b4e.1478199530.git.marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Thu, 3 Nov 2016 17:03:41 -0200
> sctp_wait_for_connect() currently already holds the asoc to keep it
> alive during the sleep, in case another thread release it. But Andrey
> Konovalov and Dmitry Vyukov reported an use-after-free in such
> situation.
>
> Problem is that __sctp_connect() doesn't get a ref on the asoc and will
> do a read on the asoc after calling sctp_wait_for_connect(), but by then
> another thread may have closed it and the _put on sctp_wait_for_connect
> will actually release it, causing the use-after-free.
>
> Fix is, instead of doing the read after waiting for the connect, do it
> before so, and avoid this issue as the socket is still locked by then.
> There should be no issue on returning the asoc id in case of failure as
> the application shouldn't trust on that number in such situations
> anyway.
>
> This issue doesn't exist in sctp_sendmsg() path.
>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net v2 0/4] net: fix device reference leaks
From: David Miller @ 2016-11-07 18:18 UTC (permalink / raw)
To: johan
Cc: f.fainelli, mugunthanvnm, yisen.zhuang, salil.mehta, netdev,
linux-kernel
In-Reply-To: <1478194822-29545-1-git-send-email-johan@kernel.org>
From: Johan Hovold <johan@kernel.org>
Date: Thu, 3 Nov 2016 18:40:18 +0100
> This series fixes a number of device reference leaks (and one of_node
> leak) due to failure to drop the references taken by bus_find_device()
> and friends.
>
> Note that the final two patches have been compile tested only.
...
> v2
> - hold reference to cpsw-phy-sel device while accessing private data as
> requested by David. Also update the commit message. (patch 1/4)
> - add linux-omap on CC where appropriate
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: icmp_route_lookup should use rt dev to determine L3 domain
From: David Miller @ 2016-11-07 18:16 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1478193219-5288-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 3 Nov 2016 10:13:39 -0700
> icmp_send is called in response to some event. The skb may not have
> the device set (skb->dev is NULL), but it is expected to have an rt.
> Update icmp_route_lookup to use the rt on the skb to determine L3
> domain.
>
> Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
"skb_dst(...)->dev" would be more direct and look nicer. No need to
use skb_rtable() just to walk backwards to the 'dst'.
^ permalink raw reply
* Re: [PATCH net-next] net: Update raw socket bind to consider l3 domain
From: David Miller @ 2016-11-07 18:15 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1478190300-14094-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 3 Nov 2016 09:25:00 -0700
> Binding a raw socket to a local address fails if the socket is bound
> to an L3 domain:
>
> $ vrf-test -s -l 10.100.1.2 -R -I red
> error binding socket: 99: Cannot assign requested address
>
> Update raw_bind to look consider if sk_bound_dev_if is bound to an L3
> domain and use inet_addr_type_table to lookup the address.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 0/3] qdisc and tx_queue_len cleanups for IFF_NO_QUEUE devices
From: David Miller @ 2016-11-07 18:13 UTC (permalink / raw)
To: brouer; +Cc: netdev, phil, robert, jhs
In-Reply-To: <20161103135534.28737.37657.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Thu, 03 Nov 2016 14:55:56 +0100
> This patchset is a cleanup for IFF_NO_QUEUE devices. It will
> hopefully help userspace get a more consistent behavior when attaching
> qdisc to such virtual devices.
I'm still thinking about this.
My reservation about this is basically since the one known offender in
userspace acknowledged that what it was doing wrong, and fixed it
quickly already, I see no reason to explicitly accomodate this.
^ permalink raw reply
* Re: [PATCH v6 0/7] add NS2 support to bgmac
From: David Miller @ 2016-11-07 18:11 UTC (permalink / raw)
To: jon.mason
Cc: robh+dt, mark.rutland, f.fainelli, rafal,
bcm-kernel-feedback-list, netdev, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1478236262-3351-1-git-send-email-jon.mason@broadcom.com>
From: Jon Mason <jon.mason@broadcom.com>
Date: Fri, 4 Nov 2016 01:10:55 -0400
> Changes in v6:
> * Use a common bgmac_phy_connect_direct (per Rafal Milecki)
> * Rebased on latest net-next
> * Added Reviewed-by to the relevant patches
>
>
> Changes in v5:
> * Change a pr_err to netdev_err (per Scott Branden)
> * Reword the lane swap binding documentation (per Andrew Lunn)
>
>
> Changes in v4:
> * Actually send out the lane swap binding doc patch (Per Scott Branden)
> * Remove unused #define (Per Andrew Lunn)
>
>
> Changes in v3:
> * Clean-up the bgmac DT binding doc (per Rob Herring)
> * Document the lane swap binding and make it generic (Per Andrew Lunn)
>
>
> Changes in v2:
> * Remove the PHY power-on (per Andrew Lunn)
> * Misc PHY clean-ups regarding comments and #defines (per Andrew Lunn)
> This results on none of the original PHY code from Vikas being
> present. So, I'm removing him as an author and giving him
> "Inspired-by" credit.
> * Move PHY lane swapping to PHY driver (per Andrew Lunn and Florian
> Fainelli)
> * Remove bgmac sleep (per Florian Fainelli)
> * Re-add bgmac chip reset (per Florian Fainelli and Ray Jui)
> * Rebased on latest net-next
> * Added patch for bcm54xx_auxctl_read, which is used in the BCM54810
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/5] net: l2tp: fix L2TP_ATTR_UDP_CSUM attribute type
From: David Miller @ 2016-11-07 18:08 UTC (permalink / raw)
To: asbjorn; +Cc: jchapman, netdev, linux-kernel, shankerwangmiao
In-Reply-To: <20161104224838.7925-1-asbjorn@asbjorn.st>
From: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
Date: Fri, 4 Nov 2016 22:48:34 +0000
> L2TP_ATTR_UDP_CSUM is a flag, and gets read with
> nla_get_flag, but it is defined as NLA_U8 in
> the nla_policy.
>
> It appears that this is only publicly used in
> iproute2, where it's broken, because it's used as
> a NLA_FLAG, and fails validation as a NLA_U8.
>
> The only place it's used as a NLA_U8 is in
> l2tp_nl_tunnel_send(), but iproute2 again reads that
> as a flag, it's therefore always set. Fortunately
> it is never used for anything, just read.
>
> CC: Miao Wang <shankerwangmiao@gmail.com>
> Signed-off-by: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
This is definitely the wrong way to go about this.
The kernel is everywhere and updating iproute2 is infinitely
easier for users to do than updating the kernel.
And in any event, once exported we really should never change
the API of anything shown to userspace like this. Just because
you can't find a user out there doesn't mean it doesn't exist.
Please instead fix iproute2 to use u8 attributes for this.
Thanks.
^ permalink raw reply
* Re: stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: Martin Blumenstingl @ 2016-11-07 17:37 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: Jerome Brunet, André Roth, Alexandre Torgue, Johnson Leung,
linux-amlogic, netdev, afaerber
In-Reply-To: <3c21b0a4-43c9-0257-f8f2-c8e02cf94fbf@st.com>
Hi Peppe,
On Mon, Nov 7, 2016 at 11:59 AM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> In the meantime, I will read again the thread just to see if
> there is something I am missing.
if you are re-reading this thread: please note that there are two
devices in discussion here!
Both are using the Amlogic S905 (GXBB) SoC and both are experiencing
the same issue (Gbit TX issues, RX with Gbit speeds and RX/TX with
100Mbit speed are NOT affected):
- Odroid-C2 (used by Jerome and André Roth)
- Tronsmart Vega S95 Meta (my device)
The (Gbit TX) problem seems to be gone on the Odroid-C2 with Jerome's
patch which disables EEE in drivers/net/phy/realtek.c (at least in his
tests, I don't have that device so I can't verify).
The same problem still appears on my Tronsmart Vega S95 Meta even with
the patched PHY driver.
Unfortunately I don't have a second device to rule out that my
Tronsmart Vega S95 Meta could be broken (not unlikely, I get DDR
errors from time to time in u-boot). Maybe Andreas Faerber can test
ethernet with and without Jerome's patch on one of his Tronsmart
devices.
Regards,
Martin
^ permalink raw reply
* Re: [lkp] [net] af1fee9821: BUG:spinlock_trylock_failure_on_UP_on_CPU
From: Andrew Lunn @ 2016-11-07 17:34 UTC (permalink / raw)
To: Allan W. Nielsen
Cc: kernel test robot, Raju Lakkaraju, David S. Miller, LKML, netdev,
lkp
In-Reply-To: <20161107132714.GA10669@microsemi.com>
On Mon, Nov 07, 2016 at 02:27:14PM +0100, Allan W. Nielsen wrote:
> Hi,
>
> I tried to get this "lkp" up and running, but I had some troubles gettting
> these scripts to work.
>
> But it seems like it can be reproduced using th eprovided config file, and qemu.
>
> Here is what I did:
>
> # reproduce original bug
> git reset --hard af1fee98219992ba2c12441a447719652ed7e983
> mkdir bug-build
> cp config-4.8.0-14895-gaf1fee9 bug-build/.config
> make O=bug-build oldconfig
> make O=bug-build -j8
> qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G -kernel \
> ../net-next/bug-build/arch/x86_64/boot/bzImage -nographic
> <see-output-1-below>
> # bug seemed to be re-produced
>
>
> # Try previous version
> git reset --hard 32ab0a38f0bd554cc45203ff4fdb6b0fdea6f025
> make O=bug-build oldconfig
> make O=bug-build -j8
> qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G -kernel \
> ../net-next/bug-build/arch/x86_64/boot/bzImage -nographic
> <see-output-2-below>
> # bug seemed to disappear
>
>
> # Try the buggy revision again - but without MICROSEMI_PHY
> git reset --hard af1fee98219992ba2c12441a447719652ed7e983
> sed -e "/MICROSEMI_PHY/d" -i bug-build/.config
> make O=bug-build oldconfig
> cat bug-build/.config | grep MICROSEMI_PHY
> qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G -kernel \
> ../net-next/bug-build/arch/x86_64/boot/bzImage -nographic
> <see-output-3-below>
> # bug still seem to be there...
>
>
> Not sure what this tells me, any hints are more than welcome.
If the bug happens without your code being compiled, it cannot be your
code. It suggests the patch is moving code around in such a way to
trigger the issue, but it is not the source of the issue itself. To me
it seems like memory corruption or uninitialised variables in some
other code, or maybe DMA from the stack, which was never allowed but
mostly work on some platforms, but the recent change to virtual mapped
stacks as broken.
Your code is off the hook, thanks for the testing you did.
Andrew
^ permalink raw reply
* RE: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
From: Madalin-Cristian Bucur @ 2016-11-07 16:59 UTC (permalink / raw)
To: David Miller
Cc: pebolle@tiscali.nl, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, ppc@mindchasers.com,
oss@buserror.net, joe@perches.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20161107.113941.669208733868640796.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, November 07, 2016 6:40 PM
>
> From: Madalin-Cristian Bucur <madalin.bucur@nxp.com>
> Date: Mon, 7 Nov 2016 16:32:16 +0000
>
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Monday, November 07, 2016 5:55 PM
> >>
> >> From: Madalin-Cristian Bucur <madalin.bucur@nxp.com>
> >> Date: Mon, 7 Nov 2016 15:43:26 +0000
> >>
> >> >> From: David Miller [mailto:davem@davemloft.net]
> >> >> Sent: Thursday, November 03, 2016 9:58 PM
> >> >>
> >> >> Why? By clearing this, you disallow an important fundamental way to
> >> >> do performane testing, via pktgen.
> >> >
> >> > The Tx path in DPAA requires one to insert a back-pointer to the skb
> >> > into
> >> > the Tx buffer. On the Tx confirmation path the back-pointer in the
> >> > buffer
> >> > is used to release the skb. If Tx buffer is shared we'd alter the
> >> > back-pointer
> >> > and leak/double free skbs. See also
> >>
> >> Then have your software state store an array of SKB pointers, one for
> each
> >> TX ring entry, just like every other driver does.
> >
> > There is no Tx ring in DPAA. Frames are send out on QMan HW queues
> > towards the FMan for Tx and then received back on Tx confirmation queues
> > for cleanup.
> > Array traversal would for sure cost more than using the back-pointer.
> > Also, we can now process confirmations on a different core than the one
> > doing Tx,
> > we'd have to keep the arrays percpu and force the Tx conf on the same
> > core. Or add locks.
>
> Report back an integer index, like every scsi driver out there which
> completes tagged queued block I/O operations asynchronously. You can
> associate the array with a specific TX confirmation queue.
>From HW? It only gives you back the buffer start address (plus length, etc).
"buff_2_skb()" needs to be solved in SW, expensively using array (lists? As
the number of frames in flight can be large/variable) or cheaply with the back
pointer. The back-pointer approach has its tradeoffs: no shared skbs, imposed
non-zero needed_headroom.
^ permalink raw reply
* [PATCH 2/2] [v2] net: qcom/emac: enable flow control if requested
From: Timur Tabi @ 2016-11-07 16:51 UTC (permalink / raw)
To: David Miller, Florian Fainelli, alokc, netdev
In-Reply-To: <1478537501-23454-1-git-send-email-timur@codeaurora.org>
If the PHY has been configured to allow pause frames, then the MAC
should be configured to generate and/or accept those frames.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
v2: fix calculation when TXFC should be set
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 70a55dc..0b4deb3 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -575,10 +575,11 @@ void emac_mac_start(struct emac_adapter *adpt)
mac |= TXEN | RXEN; /* enable RX/TX */
- /* We don't have ethtool support yet, so force flow-control mode
- * to 'full' always.
- */
- mac |= TXFC | RXFC;
+ /* Configure MAC flow control to match the PHY's settings. */
+ if (phydev->pause)
+ mac |= RXFC;
+ if (phydev->pause != phydev->asym_pause)
+ mac |= TXFC;
/* setup link speed */
mac &= ~SPEED_MASK;
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 1/2] net: qcom/emac: configure the external phy to allow pause frames
From: Timur Tabi @ 2016-11-07 16:51 UTC (permalink / raw)
To: David Miller, Florian Fainelli, alokc, netdev
In-Reply-To: <1478537501-23454-1-git-send-email-timur@codeaurora.org>
Pause frames are used to enable flow control. A MAC can send and
receive pause frames in order to throttle traffic. However, the PHY
must be configured to allow those frames to pass through.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 6fb3bee..70a55dc 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -1003,6 +1003,12 @@ int emac_mac_up(struct emac_adapter *adpt)
writel((u32)~DIS_INT, adpt->base + EMAC_INT_STATUS);
writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
+ /* Enable pause frames. Without this feature, the EMAC has been shown
+ * to receive (and drop) frames with FCS errors at gigabit connections.
+ */
+ adpt->phydev->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+ adpt->phydev->advertising |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+
adpt->phydev->irq = PHY_IGNORE_INTERRUPT;
phy_start(adpt->phydev);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 0/2] net: qcom/emac: ensure that pause frames are enabled
From: Timur Tabi @ 2016-11-07 16:51 UTC (permalink / raw)
To: David Miller, Florian Fainelli, alokc, netdev
The qcom emac driver experiences significant packet loss (through frame
check sequence errors) if flow control is not enabled and the phy is
not configured to allow pause frames to pass through it. Therefore, we
need to enable flow control and force the phy to pass pause frames.
Timur Tabi (2):
net: qcom/emac: configure the external phy to allow pause frames
[v2] net: qcom/emac: enable flow control if requested
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
From: David Miller @ 2016-11-07 16:39 UTC (permalink / raw)
To: madalin.bucur
Cc: netdev, linuxppc-dev, linux-kernel, oss, ppc, joe, pebolle,
joakim.tjernlund
In-Reply-To: <AM4PR04MB1604B2393D5CE6607204800EECA70@AM4PR04MB1604.eurprd04.prod.outlook.com>
From: Madalin-Cristian Bucur <madalin.bucur@nxp.com>
Date: Mon, 7 Nov 2016 16:32:16 +0000
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Monday, November 07, 2016 5:55 PM
>>
>> From: Madalin-Cristian Bucur <madalin.bucur@nxp.com>
>> Date: Mon, 7 Nov 2016 15:43:26 +0000
>>
>> >> From: David Miller [mailto:davem@davemloft.net]
>> >> Sent: Thursday, November 03, 2016 9:58 PM
>> >>
>> >> Why? By clearing this, you disallow an important fundamental way to do
>> >> performane testing, via pktgen.
>> >
>> > The Tx path in DPAA requires one to insert a back-pointer to the skb
>> into
>> > the Tx buffer. On the Tx confirmation path the back-pointer in the
>> buffer
>> > is used to release the skb. If Tx buffer is shared we'd alter the back-
>> pointer
>> > and leak/double free skbs. See also
>>
>> Then have your software state store an array of SKB pointers, one for each
>> TX ring entry, just like every other driver does.
>
> There is no Tx ring in DPAA. Frames are send out on QMan HW queues towards
> the FMan for Tx and then received back on Tx confirmation queues for cleanup.
> Array traversal would for sure cost more than using the back-pointer. Also,
> we can now process confirmations on a different core than the one doing Tx,
> we'd have to keep the arrays percpu and force the Tx conf on the same core.
> Or add locks.
Report back an integer index, like every scsi driver out there which
completes tagged queued block I/O operations asynchronously. You can
associate the array with a specific TX confirmation queue.
^ permalink raw reply
* RE: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
From: Madalin-Cristian Bucur @ 2016-11-07 16:32 UTC (permalink / raw)
To: David Miller
Cc: pebolle@tiscali.nl, joakim.tjernlund@transmode.se,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ppc@mindchasers.com, oss@buserror.net, joe@perches.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20161107.105500.43380129278294700.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, November 07, 2016 5:55 PM
>
> From: Madalin-Cristian Bucur <madalin.bucur@nxp.com>
> Date: Mon, 7 Nov 2016 15:43:26 +0000
>
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Thursday, November 03, 2016 9:58 PM
> >>
> >> Why? By clearing this, you disallow an important fundamental way to do
> >> performane testing, via pktgen.
> >
> > The Tx path in DPAA requires one to insert a back-pointer to the skb
> into
> > the Tx buffer. On the Tx confirmation path the back-pointer in the
> buffer
> > is used to release the skb. If Tx buffer is shared we'd alter the back-
> pointer
> > and leak/double free skbs. See also
>
> Then have your software state store an array of SKB pointers, one for each
> TX ring entry, just like every other driver does.
There is no Tx ring in DPAA. Frames are send out on QMan HW queues towards
the FMan for Tx and then received back on Tx confirmation queues for cleanup.
Array traversal would for sure cost more than using the back-pointer. Also,
we can now process confirmations on a different core than the one doing Tx,
we'd have to keep the arrays percpu and force the Tx conf on the same core.
Or add locks.
Madalin
^ 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