Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net-next] uapi/ethtool: fix spelling errors
From: David Miller @ 2018-11-18  4:34 UTC (permalink / raw)
  To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20181115232651.15948-1-sthemmin@microsoft.com>

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 15 Nov 2018 15:26:51 -0800

> Trivial spelling errors found by codespell.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] tcp: add SRTT to SCM_TIMESTAMPING_OPT_STATS
From: David Miller @ 2018-11-18  4:34 UTC (permalink / raw)
  To: ysseung; +Cc: netdev, edumazet, soheil, ncardwell, ycheng
In-Reply-To: <20181116004412.63238-1-ysseung@google.com>

From: Yousuk Seung <ysseung@google.com>
Date: Thu, 15 Nov 2018 16:44:12 -0800

> Add TCP_NLA_SRTT to SCM_TIMESTAMPING_OPT_STATS that reports the smoothed
> round trip time in microseconds (tcp_sock.srtt_us >> 3).
> 
> Signed-off-by: Yousuk Seung <ysseung@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] cxgb4: Remove SGE_HOST_PAGE_SIZE dependency on page size
From: David Miller @ 2018-11-18  4:36 UTC (permalink / raw)
  To: arjun; +Cc: netdev, nirranjan, indranil, dt, leedom, ganeshgr
In-Reply-To: <20181116034542.28846-1-arjun@chelsio.com>

From: Arjun Vynipadath <arjun@chelsio.com>
Date: Fri, 16 Nov 2018 09:15:42 +0530

> The SGE Host Page Size has nothing to do with the actual
> Host Page Size. It's the SGE's BAR2 Doorbell/GTS Page Size
> for interpreting the SGE Ingress/Egress Queue per Page values.
> Firmware reads all of these things and makes all the
> subsequent changes necessary. The Host Driver uses the SGE
> Host Page Size in order to properly calculate BAR2 Offsets.
> 
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>

Applied.

^ permalink raw reply

* Re: [PATCH] [PATCH net-next] tun: fix multiqueue rx
From: David Miller @ 2018-11-18  4:39 UTC (permalink / raw)
  To: werekraken; +Cc: jasowang, brouer, mst, edumazet, sd, netdev, matthew.cover
In-Reply-To: <20181116041016.39852-1-matthew.cover@stackpath.com>

From: Matthew Cover <werekraken@gmail.com>
Date: Thu, 15 Nov 2018 21:10:16 -0700

> When writing packets to a descriptor associated with a combined queue, the
> packets should end up on that queue.
> 
> Before this change all packets written to any descriptor associated with a
> tap interface end up on rx-0, even when the descriptor is associated with a
> different queue.
> 
> The rx traffic can be generated by either of the following.
>   1. a simple tap program which spins up multiple queues and writes packets
>      to each of the file descriptors
>   2. tx from a qemu vm with a tap multiqueue netdev
> 
> The queue for rx traffic can be observed by either of the following (done
> on the hypervisor in the qemu case).
>   1. a simple netmap program which opens and reads from per-queue
>      descriptors
>   2. configuring RPS and doing per-cpu captures with rxtxcpu
> 
> Alternatively, if you printk() the return value of skb_get_rx_queue() just
> before each instance of netif_receive_skb() in tun.c, you will get 65535
> for every skb.
> 
> Calling skb_record_rx_queue() to set the rx queue to the queue_index fixes
> the association between descriptor and rx queue.
> 
> Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>

As noted by Jason, tun_xdp_one() needs this fix too.

Can you please add that to your patch and resubmit?

Thanks.

^ permalink raw reply

* Re: [PATCH] [PATCH net-next] tun: fix multiqueue rx
From: David Miller @ 2018-11-18  5:11 UTC (permalink / raw)
  To: werekraken; +Cc: jasowang, brouer, mst, edumazet, sd, netdev, matthew.cover
In-Reply-To: <20181116070015.1759-1-matthew.cover@stackpath.com>

From: Matthew Cover <werekraken@gmail.com>
Date: Fri, 16 Nov 2018 00:00:15 -0700

> When writing packets to a descriptor associated with a combined queue, the
> packets should end up on that queue.
> 
> Before this change all packets written to any descriptor associated with a
> tap interface end up on rx-0, even when the descriptor is associated with a
> different queue.
> 
> The rx traffic can be generated by either of the following.
>   1. a simple tap program which spins up multiple queues and writes packets
>      to each of the file descriptors
>   2. tx from a qemu vm with a tap multiqueue netdev
> 
> The queue for rx traffic can be observed by either of the following (done
> on the hypervisor in the qemu case).
>   1. a simple netmap program which opens and reads from per-queue
>      descriptors
>   2. configuring RPS and doing per-cpu captures with rxtxcpu
> 
> Alternatively, if you printk() the return value of skb_get_rx_queue() just
> before each instance of netif_receive_skb() in tun.c, you will get 65535
> for every skb.
> 
> Calling skb_record_rx_queue() to set the rx queue to the queue_index fixes
> the association between descriptor and rx queue.
> 
> Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>

If this is intended to target -stable as well, which some responses seem to
indicate, you need to respin and submit this against 'net'.

Thanks.

^ permalink raw reply

* Re: [PATCH 00/10] add flow_rule infrastructure
From: David Miller @ 2018-11-18  5:14 UTC (permalink / raw)
  To: gerlitz.or
  Cc: pablo, netdev, thomas.lendacky, f.fainelli, ariel.elior,
	michael.chan, santosh, madalin.bucur, yisen.zhuang, salil.mehta,
	jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, jakub.kicinski,
	peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
	alexandre.torgue, joabreu, linux-net-drivers, ganeshgr
In-Reply-To: <CAJ3xEMggYhmdk0eRQnOgoxBx80y_GprH-AOjXCC5WkeGP+hU1A@mail.gmail.com>

From: Or Gerlitz <gerlitz.or@gmail.com>
Date: Fri, 16 Nov 2018 12:29:29 +0200

> I think it would be fair to ask for one such driver porting to see
> the impact/benefit.

This is an absolute requirement, otherwise the claim that it helps is
pure theory.

^ permalink raw reply

* Re: [PATCH v2 11/25] net: cadence: switch to using nvmem_get_mac_address()
From: Nicolas.Ferre @ 2018-11-18 15:42 UTC (permalink / raw)
  To: brgl, nsekhar, khilman, linux, arnd, gregkh, dwmw2,
	computersforpeace, boris.brezillon, marek.vasut, richard, davem,
	grygorii.strashko, srinivas.kandagatla, andrew, f.fainelli,
	robh+dt, frowand.list, wsa
  Cc: linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd, netdev,
	linux-omap, devicetree, bgolaszewski
In-Reply-To: <20181113140133.17385-12-brgl@bgdev.pl>

On 13/11/2018 at 15:01, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> We now have a generalized helper routine to read the MAC address from
> nvmem which takes struct device as argument. The nvmem subsystem will
> then try device tree first before all other potential providers.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>

> ---
>   drivers/net/ethernet/cadence/macb_main.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 1d86b4d5645a..d9a208f7bb40 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -4055,7 +4055,7 @@ static int macb_probe(struct platform_device *pdev)
>   	if (mac) {
>   		ether_addr_copy(bp->dev->dev_addr, mac);
>   	} else {
> -		err = of_get_nvmem_mac_address(np, bp->dev->dev_addr);
> +		err = nvmem_get_mac_address(&pdev->dev, bp->dev->dev_addr);
>   		if (err) {
>   			if (err == -EPROBE_DEFER)
>   				goto err_out_free_netdev;
> 


-- 
Nicolas Ferre

^ permalink raw reply

* Re: [PATCH net V3 0/5] net/smc: fixes 2018-11-12
From: David Miller @ 2018-11-18  5:29 UTC (permalink / raw)
  To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20181116123617.72948-1-ubraun@linux.ibm.com>

From: Ursula Braun <ubraun@linux.ibm.com>
Date: Fri, 16 Nov 2018 13:36:12 +0100

> v2->v3:
>    stay with 8-byte alignment for union smcd_cdc_cursor in
>    patch 4/5 "net/smc: atomic SMCD cursor handling", but get rid of
>    __packed for struct smcd_cdc_msg

This SMC-D message is defined in some standard somewhere, right?  So
if this __packed removal changes the layout it will break things.

I see smc_cdc_msg has the same issue, and it's layout is defined in
RFC7609.

If the __packed removal doesn't change the layout, you should remove it
from smc_cdc_msg too for consistency.

This is why I tell people to never use __packed.

^ permalink raw reply

* Re: [PATCH] socket: do a generic_file_splice_read when proto_ops has no splice_read
From: David Miller @ 2018-11-18  5:34 UTC (permalink / raw)
  To: kaslevs; +Cc: netdev
In-Reply-To: <20181116092753.18763-1-kaslevs@vmware.com>

From: kaslevs@vmware.com
Date: Fri, 16 Nov 2018 11:27:53 +0200

> From: Slavomir Kaslev <kaslevs@vmware.com>
> 
> splice(2) fails with -EINVAL when called reading on a socket with no splice_read
> set in its proto_ops (such as vsock sockets). Switch this to fallbacks to a
> generic_file_splice_read instead.
> 
> Signed-off-by: Slavomir Kaslev <kaslevs@vmware.com>

Applied.

I wonder why we left things this way for so long.

^ permalink raw reply

* Re: [PATCH net-next] net: align pcpu_sw_netstats and pcpu_lstats structs
From: David Miller @ 2018-11-18  5:37 UTC (permalink / raw)
  To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181116152424.222826-1-edumazet@google.com>

From: Eric Dumazet <edumazet@google.com>
Date: Fri, 16 Nov 2018 07:24:24 -0800

> Do not risk spanning these small structures on two cache lines,
> it is absolutely not worth it.
> 
> For 32bit arches, the hint might not be enough, but we do not
> really care anymore.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] net: align gnet_stats_basic_cpu struct
From: David Miller @ 2018-11-18  5:37 UTC (permalink / raw)
  To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181116154329.247947-1-edumazet@google.com>

From: Eric Dumazet <edumazet@google.com>
Date: Fri, 16 Nov 2018 07:43:29 -0800

> This structure is small (12 or 16 bytes depending on 64bit
> or 32bit kernels), but we do not want it spanning two cache lines.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH net v3] net: bridge: fix vlan stats use-after-free on destruction
From: David Miller @ 2018-11-18  5:39 UTC (permalink / raw)
  To: nikolay; +Cc: netdev, roopa, bridge, syzkaller-bugs
In-Reply-To: <20181116165001.30896-1-nikolay@cumulusnetworks.com>

From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Fri, 16 Nov 2018 18:50:01 +0200

> Syzbot reported a use-after-free of the global vlan context on port vlan
> destruction. When I added per-port vlan stats I missed the fact that the
> global vlan context can be freed before the per-port vlan rcu callback.
> There're a few different ways to deal with this, I've chosen to add a
> new private flag that is set only when per-port stats are allocated so
> we can directly check it on destruction without dereferencing the global
> context at all. The new field in net_bridge_vlan uses a hole.
> 
> v2: cosmetic change, move the check to br_process_vlan_info where the
>     other checks are done
> v3: add change log in the patch, add private (in-kernel only) flags in a
>     hole in net_bridge_vlan struct and use that instead of mixing
>     user-space flags with private flags
> 
> Fixes: 9163a0fc1f0c ("net: bridge: add support for per-port vlan stats")
> Reported-by: syzbot+04681da557a0e49a52e5@syzkaller.appspotmail.com
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

Applied.

^ permalink raw reply

* Re: [PATCH] MAINTAINERS: Add entry for CAKE qdisc
From: David Miller @ 2018-11-18  5:40 UTC (permalink / raw)
  To: toke; +Cc: netdev, cake
In-Reply-To: <20181116201359.15922-1-toke@toke.dk>

From: Toke Høiland-Jørgensen <toke@toke.dk>
Date: Fri, 16 Nov 2018 12:13:59 -0800

> We would like the existing community to be kept in the loop for any new
> developments on CAKE; and I certainly plan to keep maintaining it. Reflect
> this in MAINTAINERS.
> 
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>

Applied, thanks Toke.

^ permalink raw reply

* Re: [PATCH v2 00/25] at24: remove
From: Boris Brezillon @ 2018-11-18 16:03 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Sekhar Nori, Kevin Hilman, Russell King, Arnd Bergmann,
	Greg Kroah-Hartman, David Woodhouse, Brian Norris, Marek Vasut,
	Richard Weinberger, Nicolas Ferre, David S . Miller,
	Grygorii Strashko, Srinivas Kandagatla, Andrew Lunn,
	Florian Fainelli, Rob Herring, Frank Rowand, Wolfram Sang,
	devicetree, netdev, lin
In-Reply-To: <20181113140133.17385-1-brgl@bgdev.pl>

On Tue, 13 Nov 2018 15:01:08 +0100
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> As far as merging of this series goes: I'd like to avoid dragging it over
> four releases. The series is logically split into five groups:
> 
> patches 1-2: nvmem and mtd changes
> patches 3-9: davinci arch-specific changes
> patches 10-13: networking changes
> patches 14-24: davinci specific again
> patch 25: final at24 change
> 
> With that I believe we can do the following: Greg KH could pick up the
> first two patches into his char-misc tree.

The char-misc tree? Why not the MTD or NVMEM tree?

> Sekhar would take the second
> group and the third would go through the networking tree since the first
> three sets are not linked in any way. This would be merged for 4.21. Then
> for the next release Sekhar would pick up 14-24, provide an immutable
> branch for me and I'd merge the final patch for at24 and send it upstream
> through Wolfram's i2c tree (maybe we could even delay the i2c PR in the
> merge window to avoid the immutable branch altogether).

^ permalink raw reply

* Re: [PATCH 1/3] bpf: respect size hint to BPF_PROG_TEST_RUN if present
From: Y Song @ 2018-11-18  5:47 UTC (permalink / raw)
  To: lmb; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-api
In-Reply-To: <20181116125329.3974-2-lmb@cloudflare.com>

On Fri, Nov 16, 2018 at 12:54 PM Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> Use data_size_out as a size hint when copying test output to user space.
> A program using BPF_PERF_OUTPUT can compare its own buffer length with
> data_size_out after the syscall to detect whether truncation has taken
> place. Callers which so far did not set data_size_in are not affected.
>
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
> ---
>  net/bpf/test_run.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> index c89c22c49015..30c57b7f4ba4 100644
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -74,8 +74,15 @@ static int bpf_test_finish(const union bpf_attr *kattr,
>  {
>         void __user *data_out = u64_to_user_ptr(kattr->test.data_out);
>         int err = -EFAULT;
> +       u32 copy_size = size;
>
> -       if (data_out && copy_to_user(data_out, data, size))
> +       /* Clamp copy if the user has provided a size hint, but copy the full
> +        * buffer if not to retain old behaviour.
> +        */
> +       if (kattr->test.data_size_out && copy_size > kattr->test.data_size_out)
> +               copy_size = kattr->test.data_size_out;
> +
> +       if (data_out && copy_to_user(data_out, data, copy_size))
>                 goto out;
>         if (copy_to_user(&uattr->test.data_size_out, &size, sizeof(size)))
>                 goto out;

if copy_size < size, maybe we should return -ENOSPC so user space is aware
of insufficient size and takes proper action? This behavior will then
be consistent
with BPF_PROG_QUERY subcommand where prog_cnt is the in/out parameter and
-ENOSPC is returned if kernel does not have enough space to copy out
the whole data.

Also, since data_size_out field now has more complex semantics, could you add
some comments in uapi/linux/bpf.h so it will be relatively clear from
uapi header
how this field will be used?

> --
> 2.17.1
>

^ permalink raw reply

* Re: [PATCH net] ip_tunnel: don't force DF when MTU is locked
From: David Miller @ 2018-11-18  5:51 UTC (permalink / raw)
  To: sd; +Cc: netdev, sbrivio
In-Reply-To: <218932a71a1f19b07dc6f92daaf9baed9e532cfe.1542382139.git.sd@queasysnail.net>

From: Sabrina Dubroca <sd@queasysnail.net>
Date: Fri, 16 Nov 2018 16:58:19 +0100

> The various types of tunnels running over IPv4 can ask to set the DF
> bit to do PMTU discovery. However, PMTU discovery is subject to the
> threshold set by the net.ipv4.route.min_pmtu sysctl, and is also
> disabled on routes with "mtu lock". In those cases, we shouldn't set
> the DF bit.
> 
> This patch makes setting the DF bit conditional on the route's MTU
> locking state.
> 
> This issue seems to be older than git history.
> 
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>

Applied and queued up for -stable.

^ permalink raw reply

* [PATCH net] net-gro: reset skb->pkt_type in napi_reuse_skb()
From: Eric Dumazet @ 2018-11-18  5:51 UTC (permalink / raw)
  To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet

eth_type_trans() assumes initial value for skb->pkt_type
is PACKET_HOST.

This is indeed the value right after a fresh skb allocation.

However, it is possible that GRO merged a packet with a different
value (like PACKET_OTHERHOST in case macvlan is used), so
we need to make sure napi->skb will have pkt_type set back to
PACKET_HOST.

Otherwise, valid packets might be dropped by the stack because
their pkt_type is not PACKET_HOST.

napi_reuse_skb() was added in commit 96e93eab2033 ("gro: Add
internal interfaces for VLAN"), but this bug always has
been there.

Fixes: 96e93eab2033 ("gro: Add internal interfaces for VLAN")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/core/dev.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 0ffcbdd55fa9ee545c807f2ed3fc178830e3075a..689ff83af855660f8b9aaa0266b5e509cd0839cb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5655,6 +5655,11 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
 	skb->vlan_tci = 0;
 	skb->dev = napi->dev;
 	skb->skb_iif = 0;
+
+	/* eth_type_trans() assumes pkt_type is PACKET_HOST */
+	WARN_ON_ONCE(skb->pkt_type != PACKET_HOST);
+	skb->pkt_type = PACKET_HOST;
+
 	skb->encapsulation = 0;
 	skb_shinfo(skb)->gso_type = 0;
 	skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
-- 
2.19.1.1215.g8438c0b245-goog

^ permalink raw reply related

* Re: [PATCH 2/3] libbpf: require size hint in bpf_prog_test_run
From: Y Song @ 2018-11-18  5:53 UTC (permalink / raw)
  To: lmb; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-api
In-Reply-To: <20181116125329.3974-3-lmb@cloudflare.com>

On Fri, Nov 16, 2018 at 12:54 PM Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> Require size_out to be non-NULL if data_out is given. This prevents
> accidental overwriting of process memory after the output buffer.
>
> Adjust callers of bpf_prog_test_run to this behaviour.
>
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
> ---
>  tools/lib/bpf/bpf.c                      |  4 +++-
>  tools/testing/selftests/bpf/test_progs.c | 10 ++++++++++
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 03f9bcc4ef50..127a9aa6170e 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -403,10 +403,12 @@ int bpf_prog_test_run(int prog_fd, int repeat, void *data, __u32 size,
>         attr.test.data_in = ptr_to_u64(data);
>         attr.test.data_out = ptr_to_u64(data_out);
>         attr.test.data_size_in = size;
> +       if (data_out)
> +               attr.test.data_size_out = *size_out;

Maybe it is better to return error (-EINVAL) instead of segfault if
size_out is NULL?
we should try to avoid segfault inside the library. This will change
original API behavior, but
I think it is okay since it is in the user space.

>         attr.test.repeat = repeat;
>
>         ret = sys_bpf(BPF_PROG_TEST_RUN, &attr, sizeof(attr));
> -       if (size_out)
> +       if (data_out)
>                 *size_out = attr.test.data_size_out;
>         if (retval)
>                 *retval = attr.test.retval;
> diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
> index 2d3c04f45530..560d7527b86b 100644
> --- a/tools/testing/selftests/bpf/test_progs.c
> +++ b/tools/testing/selftests/bpf/test_progs.c
> @@ -150,6 +150,7 @@ static void test_xdp(void)
>         bpf_map_update_elem(map_fd, &key4, &value4, 0);
>         bpf_map_update_elem(map_fd, &key6, &value6, 0);
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, 1, &pkt_v4, sizeof(pkt_v4),
>                                 buf, &size, &retval, &duration);
>
> @@ -158,6 +159,7 @@ static void test_xdp(void)
>               "err %d errno %d retval %d size %d\n",
>               err, errno, retval, size);
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, 1, &pkt_v6, sizeof(pkt_v6),
>                                 buf, &size, &retval, &duration);
>         CHECK(err || retval != XDP_TX || size != 114 ||
> @@ -182,6 +184,7 @@ static void test_xdp_adjust_tail(void)
>                 return;
>         }
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, 1, &pkt_v4, sizeof(pkt_v4),
>                                 buf, &size, &retval, &duration);
>
> @@ -189,6 +192,7 @@ static void test_xdp_adjust_tail(void)
>               "ipv4", "err %d errno %d retval %d size %d\n",
>               err, errno, retval, size);
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, 1, &pkt_v6, sizeof(pkt_v6),
>                                 buf, &size, &retval, &duration);
>         CHECK(err || retval != XDP_TX || size != 54,
> @@ -252,6 +256,7 @@ static void test_l4lb(const char *file)
>                 goto out;
>         bpf_map_update_elem(map_fd, &real_num, &real_def, 0);
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, NUM_ITER, &pkt_v4, sizeof(pkt_v4),
>                                 buf, &size, &retval, &duration);
>         CHECK(err || retval != 7/*TC_ACT_REDIRECT*/ || size != 54 ||
> @@ -259,6 +264,7 @@ static void test_l4lb(const char *file)
>               "err %d errno %d retval %d size %d magic %x\n",
>               err, errno, retval, size, *magic);
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, NUM_ITER, &pkt_v6, sizeof(pkt_v6),
>                                 buf, &size, &retval, &duration);
>         CHECK(err || retval != 7/*TC_ACT_REDIRECT*/ || size != 74 ||
> @@ -341,6 +347,7 @@ static void test_xdp_noinline(void)
>                 goto out;
>         bpf_map_update_elem(map_fd, &real_num, &real_def, 0);
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, NUM_ITER, &pkt_v4, sizeof(pkt_v4),
>                                 buf, &size, &retval, &duration);
>         CHECK(err || retval != 1 || size != 54 ||
> @@ -348,6 +355,7 @@ static void test_xdp_noinline(void)
>               "err %d errno %d retval %d size %d magic %x\n",
>               err, errno, retval, size, *magic);
>
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, NUM_ITER, &pkt_v6, sizeof(pkt_v6),
>                                 buf, &size, &retval, &duration);
>         CHECK(err || retval != 1 || size != 74 ||
> @@ -1795,6 +1803,7 @@ static void test_queue_stack_map(int type)
>                         pkt_v4.iph.saddr = vals[MAP_SIZE - 1 - i] * 5;
>                 }
>
> +               size = sizeof(buf);
>                 err = bpf_prog_test_run(prog_fd, 1, &pkt_v4, sizeof(pkt_v4),
>                                         buf, &size, &retval, &duration);
>                 if (err || retval || size != sizeof(pkt_v4) ||
> @@ -1808,6 +1817,7 @@ static void test_queue_stack_map(int type)
>               err, errno, retval, size, iph->daddr);
>
>         /* Queue is empty, program should return TC_ACT_SHOT */
> +       size = sizeof(buf);
>         err = bpf_prog_test_run(prog_fd, 1, &pkt_v4, sizeof(pkt_v4),
>                                 buf, &size, &retval, &duration);
>         CHECK(err || retval != 2 /* TC_ACT_SHOT */|| size != sizeof(pkt_v4),
> --
> 2.17.1
>

^ permalink raw reply

* Re: [PATCH net 0/2] Prevent uncaught exceptions in tdc
From: David Miller @ 2018-11-18  5:55 UTC (permalink / raw)
  To: lucasb; +Cc: netdev, xiyou.wangcong, jiri, kernel
In-Reply-To: <1542407876-31310-1-git-send-email-lucasb@mojatatu.com>

From: Lucas Bates <lucasb@mojatatu.com>
Date: Fri, 16 Nov 2018 17:37:54 -0500

> This patch series addresses two potential bugs in tdc that can
> cause exceptions to be raised in certain circumstances.  These
> exceptions are generally not handled, so instead we will prevent
> them from being raised.

Series applied.

^ permalink raw reply

* Re: [PATCH net] net-gro: reset skb->pkt_type in napi_reuse_skb()
From: Eric Dumazet @ 2018-11-18  5:55 UTC (permalink / raw)
  To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20181118055154.149329-1-edumazet@google.com>



On 11/17/2018 09:51 PM, Eric Dumazet wrote:
> eth_type_trans() assumes initial value for skb->pkt_type
> is PACKET_HOST.
> 
> This is indeed the value right after a fresh skb allocation.
> 
> However, it is possible that GRO merged a packet with a different
> value (like PACKET_OTHERHOST in case macvlan is used), so
> we need to make sure napi->skb will have pkt_type set back to
> PACKET_HOST.
> 
> Otherwise, valid packets might be dropped by the stack because
> their pkt_type is not PACKET_HOST.
> 
> napi_reuse_skb() was added in commit 96e93eab2033 ("gro: Add
> internal interfaces for VLAN"), but this bug always has
> been there.
> 
> Fixes: 96e93eab2033 ("gro: Add internal interfaces for VLAN")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
>  net/core/dev.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0ffcbdd55fa9ee545c807f2ed3fc178830e3075a..689ff83af855660f8b9aaa0266b5e509cd0839cb 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5655,6 +5655,11 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
>  	skb->vlan_tci = 0;
>  	skb->dev = napi->dev;
>  	skb->skb_iif = 0;
> +
> +	/* eth_type_trans() assumes pkt_type is PACKET_HOST */

> +	WARN_ON_ONCE(skb->pkt_type != PACKET_HOST);

Oops sorry for this bit, I will send a v2 without it of course.


> +	skb->pkt_type = PACKET_HOST;
> +
>  	skb->encapsulation = 0;
>  	skb_shinfo(skb)->gso_type = 0;
>  	skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
> 

^ permalink raw reply

* [PATCH v2 net] net-gro: reset skb->pkt_type in napi_reuse_skb()
From: Eric Dumazet @ 2018-11-18  5:57 UTC (permalink / raw)
  To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet

eth_type_trans() assumes initial value for skb->pkt_type
is PACKET_HOST.

This is indeed the value right after a fresh skb allocation.

However, it is possible that GRO merged a packet with a different
value (like PACKET_OTHERHOST in case macvlan is used), so
we need to make sure napi->skb will have pkt_type set back to
PACKET_HOST.

Otherwise, valid packets might be dropped by the stack because
their pkt_type is not PACKET_HOST.

napi_reuse_skb() was added in commit 96e93eab2033 ("gro: Add
internal interfaces for VLAN"), but this bug always has
been there.

Fixes: 96e93eab2033 ("gro: Add internal interfaces for VLAN")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/core/dev.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 0ffcbdd55fa9ee545c807f2ed3fc178830e3075a..066aa902d85c3e3f5ad83244b1506a446bebcb88 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5655,6 +5655,10 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
 	skb->vlan_tci = 0;
 	skb->dev = napi->dev;
 	skb->skb_iif = 0;
+
+	/* eth_type_trans() assumes pkt_type is PACKET_HOST */
+	skb->pkt_type = PACKET_HOST;
+
 	skb->encapsulation = 0;
 	skb_shinfo(skb)->gso_type = 0;
 	skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
-- 
2.19.1.1215.g8438c0b245-goog

^ permalink raw reply related

* Re: [PATCH 3/3] selftests: add a test for bpf_prog_test_run output size
From: Y Song @ 2018-11-18  5:59 UTC (permalink / raw)
  To: lmb; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, linux-api
In-Reply-To: <20181116125329.3974-4-lmb@cloudflare.com>

On Fri, Nov 16, 2018 at 12:55 PM Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> Make sure that bpf_prog_test_run returns the correct length
> in the size_out argument and that the kernel respects the
> output size hint.
>
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
> ---
>  tools/testing/selftests/bpf/test_progs.c | 34 ++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
> index 560d7527b86b..6ab98e10e86f 100644
> --- a/tools/testing/selftests/bpf/test_progs.c
> +++ b/tools/testing/selftests/bpf/test_progs.c
> @@ -124,6 +124,39 @@ static void test_pkt_access(void)
>         bpf_object__close(obj);
>  }
>
> +static void test_output_size_hint(void)
> +{
> +       const char *file = "./test_pkt_access.o";
> +       struct bpf_object *obj;
> +       __u32 retval, size, duration;
> +       int err, prog_fd;
> +       char buf[10];
> +
> +       err = bpf_prog_load(file, BPF_PROG_TYPE_SCHED_CLS, &obj, &prog_fd);
> +       if (err) {
> +               error_cnt++;
> +               return;
> +       }
CHECK can also be used here.
if (CHECK(...)) {
   goto done;
}
where label "done" is right before bpf_object__close.
> +
> +       memset(buf, 0, sizeof(buf));
> +
> +       size = 5;
> +       err = bpf_prog_test_run(prog_fd, 1, &pkt_v4, sizeof(pkt_v4),
> +                               buf, &size, &retval, &duration);
> +       CHECK(err || retval, "run",
> +             "err %d errno %d retval %d\n",
> +             err, errno, retval);
> +
> +       CHECK(size != sizeof(pkt_v4), "out_size",
> +             "incorrect output size, want %lu have %u\n",
> +             sizeof(pkt_v4), size);
> +
> +       CHECK(buf[5] != 0, "overflow",
> +             "prog_test_run ignored size hint\n");
> +
> +       bpf_object__close(obj);
> +}
> +
>  static void test_xdp(void)
>  {
>         struct vip key4 = {.protocol = 6, .family = AF_INET};
> @@ -1847,6 +1880,7 @@ int main(void)
>         jit_enabled = is_jit_enabled();
>
>         test_pkt_access();
> +       test_output_size_hint();
>         test_xdp();
>         test_xdp_adjust_tail();
>         test_l4lb_all();
> --
> 2.17.1
>

^ permalink raw reply

* Re: [PATCH v2 net] net-gro: reset skb->pkt_type in napi_reuse_skb()
From: David Miller @ 2018-11-18  6:00 UTC (permalink / raw)
  To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181118055702.150046-1-edumazet@google.com>

From: Eric Dumazet <edumazet@google.com>
Date: Sat, 17 Nov 2018 21:57:02 -0800

> eth_type_trans() assumes initial value for skb->pkt_type
> is PACKET_HOST.
> 
> This is indeed the value right after a fresh skb allocation.
> 
> However, it is possible that GRO merged a packet with a different
> value (like PACKET_OTHERHOST in case macvlan is used), so
> we need to make sure napi->skb will have pkt_type set back to
> PACKET_HOST.
> 
> Otherwise, valid packets might be dropped by the stack because
> their pkt_type is not PACKET_HOST.
> 
> napi_reuse_skb() was added in commit 96e93eab2033 ("gro: Add
> internal interfaces for VLAN"), but this bug always has
> been there.
> 
> Fixes: 96e93eab2033 ("gro: Add internal interfaces for VLAN")
> Signed-off-by: Eric Dumazet <edumazet@google.com>

I was wondering about that WARN_ON in v1 :-)

Applied and queued up for -stable.

^ permalink raw reply

* Re: [net 1/1] tipc: fix lockdep warning when reinitilaizing sockets
From: David Miller @ 2018-11-18  6:02 UTC (permalink / raw)
  To: donmalo99
  Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, jon.maloy,
	maloy, xinl, ying.xue, tipc-discussion
In-Reply-To: <1542405304-17254-1-git-send-email-jon.maloy@ericsson.com>

From: Jon Maloy <donmalo99@gmail.com>
Date: Fri, 16 Nov 2018 16:55:04 -0500

> We get the following warning:
 ...
> The reason seems to be that tipc_net_finalize()->tipc_sk_reinit() is
> calling the function rhashtable_walk_enter() within a timer interrupt.
> We fix this by executing tipc_net_finalize() in work queue context.
> 
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [net 1/1] tipc: don't assume linear buffer when reading ancillary data
From: David Miller @ 2018-11-18  6:08 UTC (permalink / raw)
  To: donmalo99
  Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, jon.maloy,
	maloy, xinl, ying.xue, tipc-discussion
In-Reply-To: <1542475026-20413-1-git-send-email-jon.maloy@ericsson.com>

From: Jon Maloy <donmalo99@gmail.com>
Date: Sat, 17 Nov 2018 12:17:06 -0500

> The code for reading ancillary data from a received buffer is assuming
> the buffer is linear. To make this assumption true we have to linearize
> the buffer before message data is read.
> 
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>

Applied and queued up for -stable, thanks Jon.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox