* Re: [PATCH v2 net 7/7] virtio_net: Differentiate sk_buff and xdp_frame on freeing
From: Michael S. Tsirkin @ 2019-01-29 22:51 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: David S. Miller, Jason Wang, netdev, virtualization
In-Reply-To: <1548722759-2470-8-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On Tue, Jan 29, 2019 at 09:45:59AM +0900, Toshiaki Makita wrote:
> We do not reset or free up unused buffers when enabling/disabling XDP,
> so it can happen that xdp_frames are freed after disabling XDP or
> sk_buffs are freed after enabling XDP on xdp tx queues.
> Thus we need to handle both forms (xdp_frames and sk_buffs) regardless
> of XDP setting.
> One way to trigger this problem is to disable XDP when napi_tx is
> enabled. In that case, virtnet_xdp_set() calls virtnet_napi_enable()
> which kicks NAPI. The NAPI handler will call virtnet_poll_cleantx()
> which invokes free_old_xmit_skbs() for queues which have been used by
> XDP.
>
> Note that even with this change we need to keep skipping
> free_old_xmit_skbs() from NAPI handlers when XDP is enabled, because XDP
> tx queues do not aquire queue locks.
>
> - v2: Use napi_consume_skb() instead of dev_consume_skb_any()
>
> Fixes: 4941d472bf95 ("virtio-net: do not reset during XDP set")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> NOTE: Dropped Acked-by because of the v2 change.
>
> drivers/net/virtio_net.c | 54 +++++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 42 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 1d454ce..2594481 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -57,6 +57,8 @@
> #define VIRTIO_XDP_TX BIT(0)
> #define VIRTIO_XDP_REDIR BIT(1)
>
> +#define VIRTIO_XDP_FLAG BIT(0)
> +
> /* RX packet size EWMA. The average packet size is used to determine the packet
> * buffer size when refilling RX rings. As the entire RX ring may be refilled
> * at once, the weight is chosen so that the EWMA will be insensitive to short-
> @@ -252,6 +254,21 @@ struct padded_vnet_hdr {
> char padding[4];
> };
>
> +static bool is_xdp_frame(void *ptr)
> +{
> + return (unsigned long)ptr & VIRTIO_XDP_FLAG;
> +}
> +
> +static void *xdp_to_ptr(struct xdp_frame *ptr)
> +{
> + return (void *)((unsigned long)ptr | VIRTIO_XDP_FLAG);
> +}
> +
> +static struct xdp_frame *ptr_to_xdp(void *ptr)
> +{
> + return (struct xdp_frame *)((unsigned long)ptr & ~VIRTIO_XDP_FLAG);
> +}
> +
> /* Converting between virtqueue no. and kernel tx/rx queue no.
> * 0:rx0 1:tx0 2:rx1 3:tx1 ... 2N:rxN 2N+1:txN 2N+2:cvq
> */
> @@ -462,7 +479,8 @@ static int __virtnet_xdp_xmit_one(struct virtnet_info *vi,
>
> sg_init_one(sq->sg, xdpf->data, xdpf->len);
>
> - err = virtqueue_add_outbuf(sq->vq, sq->sg, 1, xdpf, GFP_ATOMIC);
> + err = virtqueue_add_outbuf(sq->vq, sq->sg, 1, xdp_to_ptr(xdpf),
> + GFP_ATOMIC);
> if (unlikely(err))
> return -ENOSPC; /* Caller handle free/refcnt */
>
> @@ -482,13 +500,13 @@ static int virtnet_xdp_xmit(struct net_device *dev,
> {
> struct virtnet_info *vi = netdev_priv(dev);
> struct receive_queue *rq = vi->rq;
> - struct xdp_frame *xdpf_sent;
> struct bpf_prog *xdp_prog;
> struct send_queue *sq;
> unsigned int len;
> int drops = 0;
> int kicks = 0;
> int ret, err;
> + void *ptr;
> int i;
>
> /* Only allow ndo_xdp_xmit if XDP is loaded on dev, as this
> @@ -507,8 +525,12 @@ static int virtnet_xdp_xmit(struct net_device *dev,
> }
>
> /* Free up any pending old buffers before queueing new ones. */
> - while ((xdpf_sent = virtqueue_get_buf(sq->vq, &len)) != NULL)
> - xdp_return_frame(xdpf_sent);
> + while ((ptr = virtqueue_get_buf(sq->vq, &len)) != NULL) {
> + if (likely(is_xdp_frame(ptr)))
> + xdp_return_frame(ptr_to_xdp(ptr));
> + else
> + napi_consume_skb(ptr, false);
> + }
>
> for (i = 0; i < n; i++) {
> struct xdp_frame *xdpf = frames[i];
> @@ -1329,18 +1351,26 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
>
> static void free_old_xmit_skbs(struct send_queue *sq, bool in_napi)
> {
> - struct sk_buff *skb;
> unsigned int len;
> unsigned int packets = 0;
> unsigned int bytes = 0;
> + void *ptr;
>
> - while ((skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
> - pr_debug("Sent skb %p\n", skb);
> + while ((ptr = virtqueue_get_buf(sq->vq, &len)) != NULL) {
> + if (likely(!is_xdp_frame(ptr))) {
> + struct sk_buff *skb = ptr;
>
> - bytes += skb->len;
> - packets++;
> + pr_debug("Sent skb %p\n", skb);
>
> - napi_consume_skb(skb, in_napi);
> + bytes += skb->len;
> + napi_consume_skb(skb, in_napi);
> + } else {
> + struct xdp_frame *frame = ptr_to_xdp(ptr);
> +
> + bytes += frame->len;
> + xdp_return_frame(frame);
> + }
> + packets++;
> }
>
> /* Avoid overhead when no packets have been processed
> @@ -2666,10 +2696,10 @@ static void free_unused_bufs(struct virtnet_info *vi)
> for (i = 0; i < vi->max_queue_pairs; i++) {
> struct virtqueue *vq = vi->sq[i].vq;
> while ((buf = virtqueue_detach_unused_buf(vq)) != NULL) {
> - if (!is_xdp_raw_buffer_queue(vi, i))
> + if (!is_xdp_frame(buf))
> dev_kfree_skb(buf);
> else
> - xdp_return_frame(buf);
> + xdp_return_frame(ptr_to_xdp(buf));
> }
> }
>
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v2 net 5/7] virtio_net: Don't process redirected XDP frames when XDP is disabled
From: Michael S. Tsirkin @ 2019-01-29 22:50 UTC (permalink / raw)
To: Toshiaki Makita
Cc: David S. Miller, Jason Wang, netdev, virtualization,
Jesper Dangaard Brouer
In-Reply-To: <1548722759-2470-6-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On Tue, Jan 29, 2019 at 09:45:57AM +0900, Toshiaki Makita wrote:
> Commit 8dcc5b0ab0ec ("virtio_net: fix ndo_xdp_xmit crash towards dev not
> ready for XDP") tried to avoid access to unexpected sq while XDP is
> disabled, but was not complete.
>
> There was a small window which causes out of bounds sq access in
> virtnet_xdp_xmit() while disabling XDP.
>
> An example case of
> - curr_queue_pairs = 6 (2 for SKB and 4 for XDP)
> - online_cpu_num = xdp_queue_paris = 4
> when XDP is enabled:
>
> CPU 0 CPU 1
> (Disabling XDP) (Processing redirected XDP frames)
>
> virtnet_xdp_xmit()
> virtnet_xdp_set()
> _virtnet_set_queues()
> set curr_queue_pairs (2)
> check if rq->xdp_prog is not NULL
> virtnet_xdp_sq(vi)
> qp = curr_queue_pairs -
> xdp_queue_pairs +
> smp_processor_id()
> = 2 - 4 + 1 = -1
> sq = &vi->sq[qp] // out of bounds access
> set xdp_queue_pairs (0)
> rq->xdp_prog = NULL
>
> Basically we should not change curr_queue_pairs and xdp_queue_pairs
> while someone can read the values. Thus, when disabling XDP, assign NULL
> to rq->xdp_prog first, and wait for RCU grace period, then change
> xxx_queue_pairs.
> Note that we need to keep the current order when enabling XDP though.
>
> - v2: Make rcu_assign_pointer/synchronize_net conditional instead of
> _virtnet_set_queues.
>
> Fixes: 186b3c998c50 ("virtio-net: support XDP_REDIRECT")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 33 ++++++++++++++++++++++++++-------
> 1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 669b65c..cea52e4 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2410,6 +2410,10 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog,
> return -ENOMEM;
> }
>
> + old_prog = rtnl_dereference(vi->rq[0].xdp_prog);
> + if (!prog && !old_prog)
> + return 0;
> +
> if (prog) {
> prog = bpf_prog_add(prog, vi->max_queue_pairs - 1);
> if (IS_ERR(prog))
> @@ -2424,21 +2428,30 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog,
> }
> }
>
> + if (!prog) {
> + for (i = 0; i < vi->max_queue_pairs; i++) {
> + rcu_assign_pointer(vi->rq[i].xdp_prog, prog);
> + if (i == 0)
> + virtnet_restore_guest_offloads(vi);
> + }
> + synchronize_net();
> + }
> +
> err = _virtnet_set_queues(vi, curr_qp + xdp_qp);
> if (err)
> goto err;
> netif_set_real_num_rx_queues(dev, curr_qp + xdp_qp);
> vi->xdp_queue_pairs = xdp_qp;
>
> - for (i = 0; i < vi->max_queue_pairs; i++) {
> - old_prog = rtnl_dereference(vi->rq[i].xdp_prog);
> - rcu_assign_pointer(vi->rq[i].xdp_prog, prog);
> - if (i == 0) {
> - if (!old_prog)
> + if (prog) {
> + for (i = 0; i < vi->max_queue_pairs; i++) {
> + rcu_assign_pointer(vi->rq[i].xdp_prog, prog);
> + if (i == 0 && !old_prog)
> virtnet_clear_guest_offloads(vi);
> - if (!prog)
> - virtnet_restore_guest_offloads(vi);
> }
> + }
> +
> + for (i = 0; i < vi->max_queue_pairs; i++) {
> if (old_prog)
> bpf_prog_put(old_prog);
> if (netif_running(dev)) {
> @@ -2451,6 +2464,12 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog,
> return 0;
>
> err:
> + if (!prog) {
> + virtnet_clear_guest_offloads(vi);
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + rcu_assign_pointer(vi->rq[i].xdp_prog, old_prog);
> + }
> +
> if (netif_running(dev)) {
> for (i = 0; i < vi->max_queue_pairs; i++) {
> virtnet_napi_enable(vi->rq[i].vq, &vi->rq[i].napi);
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH iproute2-next v2] netns: add subcommand to attach an existing network namespace
From: Andrea Claudi @ 2019-01-29 22:42 UTC (permalink / raw)
To: Matteo Croce; +Cc: netdev, David Ahern, Stephen Hemminger
In-Reply-To: <20190129150115.19965-1-mcroce@redhat.com>
On Tue, Jan 29, 2019 at 4:01 PM Matteo Croce <mcroce@redhat.com> wrote:
>
> ip tracks namespaces with dummy files in /var/run/netns/, but can't see
> namespaces created with other tools.
> Creating the dummy file and bind mounting the correct procfs entry will
> make ip aware of that namespace.
> Add an ip netns subcommand to automate this task.
>
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
> ---
> ip/ipnetns.c | 62 ++++++++++++++++++++++++++++++++++-----------
> man/man8/ip-netns.8 | 10 ++++++++
> 2 files changed, 57 insertions(+), 15 deletions(-)
>
> diff --git a/ip/ipnetns.c b/ip/ipnetns.c
> index 03879b49..430d8844 100644
> --- a/ip/ipnetns.c
> +++ b/ip/ipnetns.c
> @@ -28,6 +28,7 @@ static int usage(void)
> {
> fprintf(stderr, "Usage: ip netns list\n");
> fprintf(stderr, " ip netns add NAME\n");
> + fprintf(stderr, " ip netns attach NAME PID\n");
> fprintf(stderr, " ip netns set NAME NETNSID\n");
> fprintf(stderr, " ip [-all] netns delete [NAME]\n");
> fprintf(stderr, " ip netns identify [PID]\n");
> @@ -632,24 +633,40 @@ static int create_netns_dir(void)
> return 0;
> }
>
> -static int netns_add(int argc, char **argv)
> +static int netns_add(int argc, char **argv, bool create)
> {
> /* This function creates a new network namespace and
> * a new mount namespace and bind them into a well known
> * location in the filesystem based on the name provided.
> *
> + * If create is true, a new namespace will be created,
> + * otherwise an existing one will be attached to the file.
> + *
> * The mount namespace is created so that any necessary
> * userspace tweaks like remounting /sys, or bind mounting
> - * a new /etc/resolv.conf can be shared between uers.
> + * a new /etc/resolv.conf can be shared between users.
> */
> - char netns_path[PATH_MAX];
> + char netns_path[PATH_MAX], proc_path[PATH_MAX];
> const char *name;
> + pid_t pid;
> int fd;
> int made_netns_run_dir_mount = 0;
>
> - if (argc < 1) {
> - fprintf(stderr, "No netns name specified\n");
> - return -1;
> + if (create) {
> + if (argc < 1) {
> + fprintf(stderr, "No netns name specified\n");
> + return -1;
> + }
> + } else {
> + if (argc < 2) {
> + fprintf(stderr, "No netns name and PID specified\n");
> + return -1;
> + }
> +
> + if (get_s32(&pid, argv[1], 0) || !pid) {
> + fprintf(stderr, "Invalid PID: %s\n", argv[1]);
> + return -1;
> + }
> }
> name = argv[0];
>
> @@ -689,21 +706,33 @@ static int netns_add(int argc, char **argv)
> return -1;
> }
> close(fd);
> - if (unshare(CLONE_NEWNET) < 0) {
> - fprintf(stderr, "Failed to create a new network namespace \"%s\": %s\n",
> - name, strerror(errno));
> - goto out_delete;
> +
> + if (create) {
> + if (unshare(CLONE_NEWNET) < 0) {
> + fprintf(stderr, "Failed to create a new network namespace \"%s\": %s\n",
> + name, strerror(errno));
> + goto out_delete;
> + }
> +
> + strcpy(proc_path, "/proc/self/ns/net");
> + } else {
> + snprintf(proc_path, sizeof(proc_path), "/proc/%d/ns/net", pid);
> }
>
> /* Bind the netns last so I can watch for it */
> - if (mount("/proc/self/ns/net", netns_path, "none", MS_BIND, NULL) < 0) {
> - fprintf(stderr, "Bind /proc/self/ns/net -> %s failed: %s\n",
> - netns_path, strerror(errno));
> + if (mount(proc_path, netns_path, "none", MS_BIND, NULL) < 0) {
> + fprintf(stderr, "Bind %s -> %s failed: %s\n",
> + proc_path, netns_path, strerror(errno));
> goto out_delete;
> }
> return 0;
> out_delete:
> - netns_delete(argc, argv);
> + if (create) {
> + netns_delete(argc, argv);
> + } else if (unlink(netns_path) < 0) {
> + fprintf(stderr, "Cannot remove namespace file \"%s\": %s\n",
> + netns_path, strerror(errno));
> + }
> return -1;
> }
>
> @@ -846,7 +875,7 @@ int do_netns(int argc, char **argv)
> return usage();
>
> if (matches(*argv, "add") == 0)
> - return netns_add(argc-1, argv+1);
> + return netns_add(argc-1, argv+1, true);
>
> if (matches(*argv, "set") == 0)
> return netns_set(argc-1, argv+1);
> @@ -866,6 +895,9 @@ int do_netns(int argc, char **argv)
> if (matches(*argv, "monitor") == 0)
> return netns_monitor(argc-1, argv+1);
>
> + if (matches(*argv, "attach") == 0)
> + return netns_add(argc-1, argv+1, false);
> +
> fprintf(stderr, "Command \"%s\" is unknown, try \"ip netns help\".\n", *argv);
> exit(-1);
> }
> diff --git a/man/man8/ip-netns.8 b/man/man8/ip-netns.8
> index d539f18b..39a10e76 100644
> --- a/man/man8/ip-netns.8
> +++ b/man/man8/ip-netns.8
> @@ -19,6 +19,10 @@ ip-netns \- process network namespace management
> .B ip netns add
> .I NETNSNAME
>
> +.ti -8
> +.B ip netns attach
> +.I NETNSNAME PID
> +
> .ti -8
> .B ip [-all] netns del
> .RI "[ " NETNSNAME " ]"
> @@ -89,6 +93,12 @@ This command displays all of the network namespaces in /var/run/netns
> If NAME is available in /var/run/netns/ this command creates a new
> network namespace and assigns NAME.
>
> +.TP
> +.B ip netns attach NAME PID - create a new named network namespace
> +.sp
> +If NAME is available in /var/run/netns/ this command attaches the network
> +namespace of the process PID to NAME as if it were created with ip netns.
> +
> .TP
> .B ip [-all] netns delete [ NAME ] - delete the name of a network namespace(s)
> .sp
> --
> 2.20.1
>
Reviewed-by: Andrea Claudi <aclaudi@redhat.com>
Tested-by: Andrea Claudi <aclaudi@redhat.com>
^ permalink raw reply
* Re: Kernel memory corruption in CIPSO labeled TCP packets processing.
From: Paul Moore @ 2019-01-29 22:42 UTC (permalink / raw)
To: Nazarov Sergey
Cc: linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
netdev@vger.kernel.org, Casey Schaufler
In-Reply-To: <3499451548746609@myt4-929fb874f3f2.qloud-c.yandex.net>
On Tue, Jan 29, 2019 at 2:23 AM Nazarov Sergey <s-nazarov@yandex.ru> wrote:
> 29.01.2019, 01:18, "Paul Moore" <paul@paul-moore.com>:
> > If we don't pass a skb into ip_options_compile(), meaning both "skb"
> > and "rt" will be NULL, then I don't believe the option data will
> > change. Am I missing something?
>
> I mean, in cipso_v4_error we copy option data from skb before ip_options_compile call:
> + memcpy(opt->__data, (unsigned char *)&(ip_hdr(skb)[1]), opt->optlen);
> But skb IP header data could be already changed by first call of ip_options_compile
> when packet received.
There are several cases where the stack ends up calling icmp_send()
after the skb has been through ip_options_compile(), that should be
okay.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net v3] net: l2tp: fix reading optional fields of L2TPv3
From: Guillaume Nault @ 2019-01-29 22:37 UTC (permalink / raw)
To: Jacob Wen; +Cc: netdev, eric.dumazet
In-Reply-To: <20190129061813.8097-1-jian.w.wen@oracle.com>
On Tue, Jan 29, 2019 at 02:18:13PM +0800, Jacob Wen wrote:
> Use pskb_may_pull() to make sure the optional fields are in skb linear
> parts, so we can safely read them in l2tp_recv_common.
>
Looks fine to me. Just a few nitpicks. Not sure if they're worth a repost.
But if you send a v4, you can:
* Add the proper Fixes tag.
* Drop 'net:' from the subsystem prefix ('l2tp:' is enough).
* Move your patch history inside the commit description.
* Keep my Acked-by tag.
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index 26f1d435696a..82c28008b438 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -884,6 +884,10 @@ static int l2tp_udp_recv_core(struct l2tp_tunnel *tunnel, struct sk_buff *skb)
> goto error;
> }
>
> + if (tunnel->version != L2TP_HDR_VER_2 &&
>
Using tunnel->version == L2TP_HDR_VER_3 would have been clearer.
> diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
> index 9c9afe94d389..870f8ccf95f7 100644
> --- a/net/l2tp/l2tp_core.h
> +++ b/net/l2tp/l2tp_core.h
> @@ -301,6 +301,27 @@ static inline bool l2tp_tunnel_uses_xfrm(const struct l2tp_tunnel *tunnel)
> }
> #endif
>
> +/* Pull optional fields of L2TPv3 */
> +static inline int l2tp_v3_pull_opt(struct l2tp_session *session, struct sk_buff *skb,
>
The comment and function name are a bit misleading: nothing is pulled
here.
> + unsigned char **ptr, unsigned char **optr)
> +{
> + int opt_len = session->peer_cookie_len + l2tp_get_l2specific_len(session);
> +
> + if (opt_len > 0) {
> + int off = *ptr - *optr;
> +
> + if (!pskb_may_pull(skb, off + opt_len))
> + return -1;
> +
> + if (skb->data != *optr) {
> + *optr = skb->data;
> + *ptr = skb->data + off;
> + }
> + }
> +
> + return 0;
> +}
> +
> #define l2tp_printk(ptr, type, func, fmt, ...) \
> do { \
> if (((ptr)->debug) & (type)) \
Fixes: f7faffa3ff8e ("l2tp: Add L2TPv3 protocol support")
Fixes: 0d76751fad77 ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
Fixes: a32e0eec7042 ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")
Acked-by: Guillaume Nault <gnault@redhat.com>
Thanks for reporting and fixing this.
BTW, Do you plan to also fix L2TPv2?
It looks like defining L2TP_HDR_SIZE_MAX to 14 (size of L2TPv2 header
with all optional fields) and using it in place of L2TP_HDR_SIZE_SEQ in
l2tp_udp_recv_core() should be enough.
^ permalink raw reply
* Re: [PATCH net v5 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Saeed Mahameed @ 2019-01-29 22:21 UTC (permalink / raw)
To: davem@davemloft.net, xiangxia.m.yue@gmail.com,
gerlitz.or@gmail.com
Cc: netdev@vger.kernel.org, Or Gerlitz
In-Reply-To: <1548718086-20924-2-git-send-email-xiangxia.m.yue@gmail.com>
On Mon, 2019-01-28 at 15:28 -0800, xiangxia.m.yue@gmail.com wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> In some case, we may use multiple pedit actions to modify packets.
> The command shown as below: the last pedit action is effective.
>
> $ tc filter add dev netdev_rep parent ffff: protocol ip prio 1 \
> flower skip_sw ip_proto icmp dst_ip 3.3.3.3 \
> action pedit ex munge ip dst set 192.168.1.100 pipe \
> action pedit ex munge eth src set 00:00:00:00:00:01 pipe \
> action pedit ex munge eth dst set 00:00:00:00:00:02 pipe \
> action csum ip pipe \
> action tunnel_key set src_ip 1.1.1.100 dst_ip 1.1.1.200
> dst_port 4789 id 100 \
> action mirred egress redirect dev vxlan0
>
> To fix it, we add max_mod_hdr_actions to mlx5e_tc_flow_parse_attr
> struction,
> max_mod_hdr_actions will store the max pedit action number we support
> and
> num_mod_hdr_actions indicates how many pedit action we used, and
> store all
> pedit action to mod_hdr_actions.
>
> Fixes: d79b6df6b10a ("net/mlx5e: Add parsing of TC pedit actions to
> HW format")
> Cc: Or Gerlitz <ogerlitz@mellanox.com>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> v3: Remove the unnecessary init.
> v2: Fix comment message and change tag from net-next to net.
> ---
Thank you Tonghao and Or.
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCH net v5 1/2] net/mlx5e: Update hw flows when encap source mac changed
From: Saeed Mahameed @ 2019-01-29 22:20 UTC (permalink / raw)
To: davem@davemloft.net, xiangxia.m.yue@gmail.com,
gerlitz.or@gmail.com
Cc: netdev@vger.kernel.org, Hadar Hen Zion
In-Reply-To: <1548718086-20924-1-git-send-email-xiangxia.m.yue@gmail.com>
On Mon, 2019-01-28 at 15:28 -0800, xiangxia.m.yue@gmail.com wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> When we offload tc filters to hardware, hardware flows can
> be updated when mac of encap destination ip is changed.
> But we ignore one case, that the mac of local encap ip can
> be changed too, so we should also update them.
>
> To fix it, add route_dev in mlx5e_encap_entry struct to save
> the local encap netdevice, and when mac changed, kernel will
> flush all the neighbour on the netdevice and send
> NETEVENT_NEIGH_UPDATE
> event. The mlx5 driver will delete the flows and add them when
> neighbour
> available again.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update
> flow")
> Cc: Hadar Hen Zion <hadarh@mellanox.com>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
>
>
Thank you Tonghao and Or.
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCH] kernel/bpf/core.c - fix bitrotted kerneldoc.
From: Song Liu @ 2019-01-29 22:12 UTC (permalink / raw)
To: Valdis Kletnieks
Cc: Alexei Starovoitov, Daniel Borkmann, Networking, open list
In-Reply-To: <30924.1548734686@turing-police.cc.vt.edu>
On Mon, Jan 28, 2019 at 8:06 PM <valdis.kletnieks@vt.edu> wrote:
>
> Over the years, the function signature has changed, the kerneldoc block hasn't.
>
> Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Acked-by: Song Liu <songliubraving@fb.com>
>
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 2a81b8af3748..2728b6247091 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1216,8 +1216,9 @@ bool bpf_opcode_in_insntable(u8 code)
> #ifndef CONFIG_BPF_JIT_ALWAYS_ON
> /**
> * __bpf_prog_run - run eBPF program on a given context
> - * @ctx: is the data we are operating on
> + * @regs: is the array of MAX_BPF_EXT_REG eBPF pseudo-registers
> * @insn: is the array of eBPF instructions
> + * @stack: is the eBPF storage stack
> *
> * Decode and execute eBPF instructions.
> */
>
^ permalink raw reply
* Re: [PATCH net-next 02/24] sctp: use SCTP_FUTURE_ASSOC for SCTP_PEER_ADDR_PARAMS sockopt
From: Neil Horman @ 2019-01-29 21:25 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, davem
In-Reply-To: <bf66a45aa6763646c07e1b8be102466f07fc1648.1548659198.git.lucien.xin@gmail.com>
On Mon, Jan 28, 2019 at 03:08:24PM +0800, Xin Long wrote:
> Check with SCTP_FUTURE_ASSOC instead in
> sctp_/setgetsockopt_peer_addr_params, it's compatible with 0.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/socket.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index a52d132..4c43b95 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2750,12 +2750,13 @@ static int sctp_setsockopt_peer_addr_params(struct sock *sk,
> return -EINVAL;
> }
>
> - /* Get association, if assoc_id != 0 and the socket is a one
> - * to many style socket, and an association was not found, then
> - * the id was invalid.
> + /* Get association, if assoc_id != SCTP_FUTURE_ASSOC and the
> + * socket is a one to many style socket, and an association
> + * was not found, then the id was invalid.
> */
> asoc = sctp_id2assoc(sk, params.spp_assoc_id);
> - if (!asoc && params.spp_assoc_id && sctp_style(sk, UDP))
> + if (!asoc && params.spp_assoc_id != SCTP_FUTURE_ASSOC &&
Sorry to follow up, but I misspoke in my previous email, I should have said, why
do we only allow future associations as the only special case association id
here? Since the function is meant to set a specific association id, it seems to
me that you would want to:
a) allow setting of a specific id
b) allow setting of all association ids on the socket
(SCTP_CURRENT_ASSOC)
c) allow recording of a set of params to apply to all current and future
associations (FUTURE/ALL).
(a) is already handled clearly, but (b) and (c) require more work on this
function than just checking association id on entry.
I think this comment may apply to all the socket option functions
> + sctp_style(sk, UDP))
> return -EINVAL;
>
> /* Heartbeat demand can only be sent on a transport or
> @@ -5676,12 +5677,13 @@ static int sctp_getsockopt_peer_addr_params(struct sock *sk, int len,
> }
> }
>
> - /* Get association, if assoc_id != 0 and the socket is a one
> - * to many style socket, and an association was not found, then
> - * the id was invalid.
> + /* Get association, if assoc_id != SCTP_FUTURE_ASSOC and the
> + * socket is a one to many style socket, and an association
> + * was not found, then the id was invalid.
> */
> asoc = sctp_id2assoc(sk, params.spp_assoc_id);
> - if (!asoc && params.spp_assoc_id && sctp_style(sk, UDP)) {
> + if (!asoc && params.spp_assoc_id != SCTP_FUTURE_ASSOC &&
> + sctp_style(sk, UDP)) {
> pr_debug("%s: failed no association\n", __func__);
> return -EINVAL;
> }
> --
> 2.1.0
>
>
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Heiner Kallweit @ 2019-01-29 21:20 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190129153553.GL27062@torres.zugschlus.de>
Hi Marc,
one more attempt, could you please test the following with 4.19 or 4.20
(w/o the other debug patches) ?
Rgds, Heiner
---
drivers/net/ethernet/realtek/r8169.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3e650bd9e..2dab28115 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1371,6 +1371,8 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
+/* Don't delete it completely, in case we need to re-enable it */
+#if 0
static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
{
u8 options;
@@ -1405,6 +1407,7 @@ static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
return wolopts;
}
+#endif
static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
{
@@ -4284,7 +4287,7 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
static bool rtl_wol_pll_power_down(struct rtl8169_private *tp)
{
- if (!__rtl8169_get_wol(tp))
+ if (!device_may_wakeup(tp_to_dev(tp)))
return false;
phy_speed_down(tp->phydev, false);
@@ -7441,8 +7444,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
return rc;
}
- tp->saved_wolopts = __rtl8169_get_wol(tp);
-
mutex_init(&tp->wk.mutex);
INIT_WORK(&tp->wk.work, rtl_task);
u64_stats_init(&tp->rx_stats.syncp);
--
2.20.1
On 29.01.2019 16:35, Marc Haber wrote:
> Hi,
>
> after having a good night's sleep over that, it's obviously a merge
> commit which cannot easily be reverted. How would I continue after
> identifying a merge commit as the culprit?
>
> On Tue, Jan 29, 2019 at 08:32:53AM +0100, Marc Haber wrote:
>> According to bisect, the first bad commit is
>> 19725496da5602b401eae389736ab00d1817e264
>>
>> commit 19725496da5602b401eae389736ab00d1817e264
>> Merge: aea5f654e6b7 9981b4fb8684
>
> git diff aea5f654e6b7..19725496da5602b401eae389736ab00d1817e264,
> filtered for r8169 looks manageable:
>
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7396,8 +7396,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struc
> return rc;
> }
>
> - /* override BIOS settings, use userspace tools to enable WOL */
> - __rtl8169_set_wol(tp, 0);
> + tp->saved_wolopts = __rtl8169_get_wol(tp);
>
> mutex_init(&tp->wk.mutex);
> u64_stats_init(&tp->rx_stats.syncp);
>
> but the other one seems unmanageably big:
>
> [18/5009]mh@fan:~/linux/git/linux (master % u=) $ git diff 9981b4fb8684..19725496da5602b401eae389736ab00d1817e264 -- drivers/net/ethernet/realtek/r8169.c | diffstat
> r8169.c | 815 ++++++++++++++++++----------------------------------------------
> 1 file changed, 234 insertions(+), 581 deletions(-)
> [19/5009]mh@fan:~/linux/git/linux (master % u=) $
>
> -------
> But, indeed, adding the call to __rtl8169_set_wol(tp, 0) fixes the issue
> for me and the machine now wakes up from StR on a magic packet without
> having to go through strange ethtool motions.
> -------
>
> Would that code change be suitable for the official kernel cod?
>
> Greetings
> Marc
>
^ permalink raw reply related
* Re: [PATCH net-next 02/24] sctp: use SCTP_FUTURE_ASSOC for SCTP_PEER_ADDR_PARAMS sockopt
From: Neil Horman @ 2019-01-29 21:17 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, davem
In-Reply-To: <bf66a45aa6763646c07e1b8be102466f07fc1648.1548659198.git.lucien.xin@gmail.com>
On Mon, Jan 28, 2019 at 03:08:24PM +0800, Xin Long wrote:
> Check with SCTP_FUTURE_ASSOC instead in
> sctp_/setgetsockopt_peer_addr_params, it's compatible with 0.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/socket.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index a52d132..4c43b95 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2750,12 +2750,13 @@ static int sctp_setsockopt_peer_addr_params(struct sock *sk,
> return -EINVAL;
> }
>
> - /* Get association, if assoc_id != 0 and the socket is a one
> - * to many style socket, and an association was not found, then
> - * the id was invalid.
> + /* Get association, if assoc_id != SCTP_FUTURE_ASSOC and the
> + * socket is a one to many style socket, and an association
> + * was not found, then the id was invalid.
> */
> asoc = sctp_id2assoc(sk, params.spp_assoc_id);
> - if (!asoc && params.spp_assoc_id && sctp_style(sk, UDP))
> + if (!asoc && params.spp_assoc_id != SCTP_FUTURE_ASSOC &&
If we are disallowing SCTP_FUTURE_ASSOC here, why would we allow SCTP_ALL_ASSOC
(which, as noted by patch 0, includes future associations)?
> + sctp_style(sk, UDP))
> return -EINVAL;
>
> /* Heartbeat demand can only be sent on a transport or
> @@ -5676,12 +5677,13 @@ static int sctp_getsockopt_peer_addr_params(struct sock *sk, int len,
> }
> }
>
> - /* Get association, if assoc_id != 0 and the socket is a one
> - * to many style socket, and an association was not found, then
> - * the id was invalid.
> + /* Get association, if assoc_id != SCTP_FUTURE_ASSOC and the
> + * socket is a one to many style socket, and an association
> + * was not found, then the id was invalid.
> */
> asoc = sctp_id2assoc(sk, params.spp_assoc_id);
> - if (!asoc && params.spp_assoc_id && sctp_style(sk, UDP)) {
> + if (!asoc && params.spp_assoc_id != SCTP_FUTURE_ASSOC &&
Same question as above, shouldn't both of these be restricted to specific
associations or to CURRENT associations?
> + sctp_style(sk, UDP)) {
> pr_debug("%s: failed no association\n", __func__);
> return -EINVAL;
> }
> --
> 2.1.0
>
>
^ permalink raw reply
* Re: ethtool - manual changes in ethtool-copy.h
From: John W. Linville @ 2019-01-29 20:47 UTC (permalink / raw)
To: Michal Kubecek; +Cc: Maciej Żenczykowski, netdev
In-Reply-To: <20190129202842.GI24651@unicorn.suse.cz>
On Tue, Jan 29, 2019 at 09:28:42PM +0100, Michal Kubecek wrote:
> Hello,
>
> I'm sorry I didn't notice earlier but ethtool commit 4df55c81996d
> ("ethtool: change to new sane powerpc64 kernel headers") adds changes to
> ethtool-copy.h which are not in sync with kernel file it is generated
> from.
>
> This file is supposed to be a copy of the sanitized kernel UAPI header,
> i.e. what you get as include/linux/ethtool.h by "make headers_install"
> in kernel tree. (The copy in ethtool git is currently a bit behind but
> the missing recent changes only modify comments so that it's not really
> a problem.)
>
> Modifying this file manually would mean that anyone who would update it
> in the future (to sync with kernel changes) could not simply copy the
> sanitized kernel header but would have to make sure to add your fragment
> to it.
>
> As you only need to define the __SANE_USERSPACE_TYPES__ macro (on
> ppc64), it might be possible to achieve the same goal in Makefile.
>
> Michal Kubecek
Ooops -- thanks for noticing that Michal!
Maciej, how soon might you be able to address this? What is the effect
of simply reverting it? Just warnings on ppc64 builds?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-01-29 20:55 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Need to save away the IV across tls async operations, from Dave
Watson.
2) Upon successful packet processing, we should liberate the SKB with
dev_consume_skb{_irq}(). From Yang Wei.
3) Only apply RX hang workaround on effected macb chips, from Harini
Katakam.
4) Dummy netdev need a proper namespace assigned to them, from Josh
Elsasser.
5) Some paths of nft_compat run lockless now, and thus we need to use
a proper refcnt_t. From Florian Westphal.
6) Avoid deadlock in mlx5 by doing IRQ locking, from Moni Shoua.
7) netrom does not refcount sockets properly wrt. timers, fix that
by using the sock timer API. From Cong Wang.
8) Fix locking of inexact inserts of xfrm policies, from Florian
Westphal.
9) Missing xfrm hash generation bump, also from Florian.
10) Missing of_node_put() in hns driver, from Yonglong Liu.
11) Fix DN_IFREQ_SIZE, from Johannes Berg.
12) ip6mr notifier is invoked during traversal of wrong table,
from Nir Dotan.
13) TX promisc settings not performed correctly in qed, from Manish
Chopra.
14) Fix OOB access in vhost, from Jason Wang.
Please pull, thanks a lot!
The following changes since commit 1fc7f56db7a7c467e46a5d2e2a009d2f337e0338:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2019-01-27 09:21:00 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to d07e1e0febe10b65eecd3205ad3bd1e999754887:
MAINTAINERS: Add entry for XDP (eXpress Data Path) (2019-01-29 11:40:51 -0800)
----------------------------------------------------------------
Alexey Khoroshilov (1):
net: stmmac: dwmac-rk: fix error handling in rk_gmac_powerup()
Anders Roxell (1):
netfilter: ipt_CLUSTERIP: fix warning unused variable cn
Andrew Lunn (1):
net: dsa: mv88e6xxx: Fix serdes irq setup going recursive
Aya Levin (1):
net/mlx5e: Allow MAC invalidation while spoofchk is ON
Benedict Wong (1):
xfrm: Make set-mark default behavior backward compatible
Bernard Pidoux (1):
net/rose: fix NULL ax25_cb kernel panic
Bodong Wang (1):
Revert "net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager"
Cong Wang (1):
netrom: switch to sock timer API
Dave Watson (2):
net: tls: Save iv in tls_rec for async crypto requests
net: tls: Fix deadlock in free_resources tx
David S. Miller (5):
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
Merge tag 'mlx5-fixes-2019-01-25' of git://git.kernel.org/.../saeed/linux
Merge branch 'hns-fixes'
Merge git://git.kernel.org/.../pablo/nf
Merge branch 'qed-Bug-fixes'
Fernando Fernandez Mancera (1):
netfilter: nfnetlink_osf: add missing fmatch check
Florian Westphal (12):
selftests: xfrm: add block rules with adjacent/overlapping subnets
xfrm: policy: use hlist rcu variants on inexact insert, part 2
xfrm: policy: increment xfrm_hash_generation on hash rebuild
xfrm: policy: delete inexact policies from inexact list on hash rebuild
xfrm: policy: fix reinsertion on node merge
selftests: xfrm: alter htresh to trigger move of policies to hash table
xfrm: policy: fix infinite loop when merging src-nodes
xfrm: refine validation of template and selector families
netfilter: nft_compat: use refcnt_t type for nft_xt reference count
netfilter: nft_compat: make lists per netns
netfilter: nft_compat: destroy function must not have side effects
netfilter: ebtables: compat: un-break 32bit setsockopt when no rules are present
Harini Katakam (1):
net: macb: Apply RXUBR workaround only to versions with errata
Jason Wang (1):
vhost: fix OOB in get_rx_bufs()
Jesper Dangaard Brouer (1):
MAINTAINERS: Add entry for XDP (eXpress Data Path)
Johannes Berg (1):
decnet: fix DN_IFREQ_SIZE
Josh Elsasser (1):
net: set default network namespace in init_dummy_netdev()
Manish Chopra (5):
qed: Fix bug in tx promiscuous mode settings
qed: Fix LACP pdu drops for VFs
qed: Fix VF probe failure while FLR
qed: Fix system crash in ll2 xmit
qed: Fix stack out of bounds bug
Moni Shoua (1):
net/mlx5: Take lock with IRQs disabled to avoid deadlock
Nir Dotan (1):
ip6mr: Fix notifiers call on mroute_clean_tables()
Or Gerlitz (2):
net/mlx5e: Move to use common phys port names for vport representors
net/mlx5e: Unblock setting vid 0 for VFs through the uplink rep
Shay Agroskin (1):
net/mlx5e: Fix wrong private flag usage causing checksum disable
Su Yanjun (1):
vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel
Tomonori Sakita (1):
net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
Yang Wei (8):
net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: alteon: replace dev_kfree_skb_irq by dev_consume_skb_irq
net: amd8111e: replace dev_kfree_skb_irq by dev_consume_skb_irq
net: apple: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: ti: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: 8139cp: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: caif: call dev_consume_skb_any when skb xmit done
net: b44: replace dev_kfree_skb_xxx by dev_consume_skb_xxx for drop profiles
Yonglong Liu (3):
net: hns: Fix for missing of_node_put() after of_parse_phandle()
net: hns: Restart autoneg need return failed when autoneg off
net: hns: Fix wrong read accesses via Clause 45 MDIO protocol
ZhangXiaoxu (1):
ipvs: Fix signed integer overflow when setsockopt timeout
MAINTAINERS | 18 ++++++++++
drivers/net/caif/caif_serial.c | 5 +--
drivers/net/dsa/mv88e6xxx/serdes.c | 2 +-
drivers/net/ethernet/alteon/acenic.c | 2 +-
drivers/net/ethernet/altera/altera_msgdma.c | 3 +-
drivers/net/ethernet/amd/amd8111e.c | 2 +-
drivers/net/ethernet/apple/bmac.c | 2 +-
drivers/net/ethernet/broadcom/b44.c | 4 +--
drivers/net/ethernet/cadence/macb.h | 3 ++
drivers/net/ethernet/cadence/macb_main.c | 28 +++++++++------
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 5 +++
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 16 +++++----
drivers/net/ethernet/hisilicon/hns_mdio.c | 2 +-
drivers/net/ethernet/i825xx/82596.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 25 +++++++++++--
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 22 +++++-------
drivers/net/ethernet/mellanox/mlx5/core/lag.c | 21 +++++++++++
drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/qp.c | 5 +--
drivers/net/ethernet/qlogic/qed/qed_dev.c | 8 ++---
drivers/net/ethernet/qlogic/qed/qed_l2.c | 12 ++++++-
drivers/net/ethernet/qlogic/qed/qed_l2.h | 3 ++
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 20 ++++++++---
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 10 ++++--
drivers/net/ethernet/qlogic/qed/qed_vf.c | 10 ++++++
drivers/net/ethernet/realtek/8139cp.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 4 ++-
drivers/net/ethernet/ti/cpmac.c | 2 +-
drivers/vhost/net.c | 3 +-
drivers/vhost/scsi.c | 2 +-
drivers/vhost/vhost.c | 7 ++--
drivers/vhost/vhost.h | 4 ++-
drivers/vhost/vsock.c | 2 +-
include/net/tls.h | 2 ++
net/bridge/netfilter/ebtables.c | 9 +++--
net/core/dev.c | 3 ++
net/decnet/dn_dev.c | 2 +-
net/ipv4/ip_vti.c | 50 ++++++++++++++++++++++++++
net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +-
net/ipv6/ip6mr.c | 7 ++--
net/netfilter/ipvs/ip_vs_ctl.c | 12 +++++++
net/netfilter/nfnetlink_osf.c | 4 +++
net/netfilter/nft_compat.c | 189 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------
net/netrom/nr_timer.c | 20 +++++------
net/rose/rose_route.c | 5 +++
net/tls/tls_sw.c | 6 +++-
net/xfrm/xfrm_policy.c | 63 +++++++++++++++++----------------
net/xfrm/xfrm_user.c | 13 ++++---
tools/testing/selftests/net/xfrm_policy.sh | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------
50 files changed, 605 insertions(+), 195 deletions(-)
^ permalink raw reply
* linux-next: Fixes tags need some work in the net tree
From: Stephen Rothwell @ 2019-01-29 20:49 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dave Watson
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
Hi all,
In commit
1023121375c6 ("net: tls: Fix deadlock in free_resources tx")
Fixes tag
Fixes: a42055e8d2c30 ("Add support for async encryption of records...")
has these problem(s):
- Subject does not match target commit subject
In commit
32eb67b93c9e ("net: tls: Save iv in tls_rec for async crypto requests")
Fixes tag
Fixes: a42055e8d2c30 ("Add support for async encryption of records...")
has these problem(s):
- Subject does not match target commit subject
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* ethtool - manual changes in ethtool-copy.h
From: Michal Kubecek @ 2019-01-29 20:28 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: John W. Linville, netdev
Hello,
I'm sorry I didn't notice earlier but ethtool commit 4df55c81996d
("ethtool: change to new sane powerpc64 kernel headers") adds changes to
ethtool-copy.h which are not in sync with kernel file it is generated
from.
This file is supposed to be a copy of the sanitized kernel UAPI header,
i.e. what you get as include/linux/ethtool.h by "make headers_install"
in kernel tree. (The copy in ethtool git is currently a bit behind but
the missing recent changes only modify comments so that it's not really
a problem.)
Modifying this file manually would mean that anyone who would update it
in the future (to sync with kernel changes) could not simply copy the
sanitized kernel header but would have to make sure to add your fragment
to it.
As you only need to define the __SANE_USERSPACE_TYPES__ macro (on
ppc64), it might be possible to achieve the same goal in Makefile.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH net-next] net: udp Allow CHECKSUM_UNNECESSARY packets to do GRO.
From: Tom Herbert @ 2019-01-29 20:24 UTC (permalink / raw)
To: maowenan; +Cc: Linux Kernel Network Developers, David S. Miller, Eric Dumazet
In-Reply-To: <f19946e5-d76d-ca75-d558-44dc8f738764@huawei.com>
On Tue, Jan 29, 2019 at 12:08 AM maowenan <maowenan@huawei.com> wrote:
>
>
>
> On 2019/1/29 14:24, Tom Herbert wrote:
> > On Mon, Jan 28, 2019 at 10:04 PM maowenan <maowenan@huawei.com> wrote:
> >>
> >>
> >>
> >> On 2019/1/29 12:01, Tom Herbert wrote:
> >>> On Mon, Jan 28, 2019 at 7:00 PM maowenan <maowenan@huawei.com> wrote:
> >>>>
> >>>> Hi all，
> >>>> Do you have any comments about this change?
> >>>>
> >>>>
> >>>> On 2019/1/23 11:33, Mao Wenan wrote:
> >>>>> When udp4_gro_receive() get one packet that uh->check=0,
> >>>>> skb_gro_checksum_validate_zero_check() will set the
> >>>>> skb->ip_summed = CHECKSUM_UNNECESSARY;
> >>>>> skb->csum_level = 0;
> >>>>> Then udp_gro_receive() will flush the packet which is not CHECKSUM_PARTIAL,
> >>>>> It is not our expect, because check=0 in udp header indicates this
> >>>>> packet is no need to caculate checksum, we should go further to do GRO.
> >>>>>
> >>>>> This patch changes the value of csum_cnt according to skb->csum_level.
> >>>>> ---
> >>>>> include/linux/netdevice.h | 1 +
> >>>>> 1 file changed, 1 insertion(+)
> >>>>>
> >>>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >>>>> index 1377d08..9c819f1 100644
> >>>>> --- a/include/linux/netdevice.h
> >>>>> +++ b/include/linux/netdevice.h
> >>>>> @@ -2764,6 +2764,7 @@ static inline void skb_gro_incr_csum_unnecessary(struct sk_buff *skb)
> >>>>> * during GRO. This saves work if we fallback to normal path.
> >>>>> */
> >>>>> __skb_incr_checksum_unnecessary(skb);
> >>>>> + NAPI_GRO_CB(skb)->csum_cnt = skb->csum_level + 1;
> >>>
> >>> That doesn't look right. This would be reinitializing the GRO
> >>> checksums from the beginning.
> >>>
> >>>>> }
> >>>>> }
> >>>>>
> >>>>>
> >>>>
> >>> I assume the code is bailing on this conditional:
> >>>
> >>> if (NAPI_GRO_CB(skb)->encap_mark ||
> >>> (skb->ip_summed != CHECKSUM_PARTIAL &&
> >>> NAPI_GRO_CB(skb)->csum_cnt == 0 &&
> >>> !NAPI_GRO_CB(skb)->csum_valid) ||
> >>> !udp_sk(sk)->gro_receive)
> >>> goto out_unlock;
> >>>
> >>> I am trying to remember why this needs to check csum_cnt. If there was
> >>> a csum_cnt for the UDP csum being zero from checksum-unnecessary, it
> >>> was consumed by skb_gro_checksum_validate_zero_check in UDP4 GRO
> >>> received.
> >>
> >> We have met the scene about two VMs in different host with vxlan packets, when udp4_gro_receive receives
> >> one packet with ip_summed=CHECKSUM_NONE,csum_cnt=0,csum_valid=0,and udp->check=0, then skb_gro_checksum_validate_zero_check()->
> >> skb_gro_incr_csum_unnecessary() validate it and set ip_summed=CHECKSUM_UNNECESSARY,csum_level=0, but csum_cnt and csum_valid
> >> keep zero value. Then it will be flushed in udp_gro_receive(), the codes as you have showed.
> >>
> >> so I think it forgets to modify csum_cnt since csum_level is changed in skb_gro_incr_csum_unnecessary()->__skb_incr_checksum_unnecessary().
> >>
> > Yes, but the csum_level is changing since we've gone beyond the
> > checksums initially reported inc checksum-unnecessary. GRO csum_cnt is
> > initialized to skb->csum_level + 1 at the start of GRO processing.
> >
> > If I recall, the rule is that UDP GRO requires at least one non-zero
> > checksum to be verified. The idea is that if we end up computing
> > packet checksums on the host for inner checksums like TCP during GRO,
> > then that's negating the performance benefits of GRO. Had UDP check
> > not been zero then we would do checksum unnecessary conversion and so
> > csum_valid would be set for the remainded of GRO processing. The
> > existing code is following the rule I believe, so this may be working
> > as intended.
>
> Do you have any suggestion if I need do GRO as udp->check is zero?
> My previous modification which works fine as below:
> if (NAPI_GRO_CB(skb)->encap_mark ||
> (skb->ip_summed != CHECKSUM_PARTIAL &&
> + skb->ip_summed != CHECKSUM_UNNECESSARY &&
That's effectively disabling the rule that we need a real checksum
calculation to proceed with GRO. Besides that, the device returning
one checksum-unnecessary level because UDP csum is zero is pretty
pointelss; we can just as easily deduce get to same state just by
looking at the field with CHECKSUM_NONE. What we really want to see
for GRO is a real checksum computation being done on the packet.
A few questions:
What type of packets are being GROed? Are these TCP? What performance
difference do you see with our patch? Can you try enabling UDP
checksums, and even RCO with VXLAN? With UDP encapsulation we
generally see better performance with checksum enabled since UDP
checksum offload is ubiquitous and we can easily convert
checksum-unnecessary (with non-zero csum) to checksum-complete.
Tom
> NAPI_GRO_CB(skb)->csum_cnt == 0 &&
> !NAPI_GRO_CB(skb)->csum_valid) ||
> !udp_sk(sk)->gro_receive)
> goto out_unlock;
>
>
> >
> > Tom
> >
> >>>
> >>> .
> >>>
> >>
> >
> > .
> >
>
^ permalink raw reply
* Re: [PATCH net v5 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Or Gerlitz @ 2019-01-29 20:17 UTC (permalink / raw)
To: David Miller, Saeed Mahameed; +Cc: Linux Netdev List, Tonghao Zhang
In-Reply-To: <1548718086-20924-2-git-send-email-xiangxia.m.yue@gmail.com>
On Tue, Jan 29, 2019 at 8:05 PM <xiangxia.m.yue@gmail.com> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> In some case, we may use multiple pedit actions to modify packets.
> The command shown as below: the last pedit action is effective.
>
> $ tc filter add dev netdev_rep parent ffff: protocol ip prio 1 \
> flower skip_sw ip_proto icmp dst_ip 3.3.3.3 \
> action pedit ex munge ip dst set 192.168.1.100 pipe \
> action pedit ex munge eth src set 00:00:00:00:00:01 pipe \
> action pedit ex munge eth dst set 00:00:00:00:00:02 pipe \
> action csum ip pipe \
> action tunnel_key set src_ip 1.1.1.100 dst_ip 1.1.1.200 dst_port 4789 id 100 \
> action mirred egress redirect dev vxlan0
>
> To fix it, we add max_mod_hdr_actions to mlx5e_tc_flow_parse_attr struction,
> max_mod_hdr_actions will store the max pedit action number we support and
> num_mod_hdr_actions indicates how many pedit action we used, and store all
> pedit action to mod_hdr_actions.
>
> Fixes: d79b6df6b10a ("net/mlx5e: Add parsing of TC pedit actions to HW format")
> Cc: Or Gerlitz <ogerlitz@mellanox.com>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> v3: Remove the unnecessary init.
> v2: Fix comment message and change tag from net-next to net.
Same here, this is good to go upstream, well done Tonghao!
^ permalink raw reply
* Re: [PATCH net v5 1/2] net/mlx5e: Update hw flows when encap source mac changed
From: Or Gerlitz @ 2019-01-29 20:16 UTC (permalink / raw)
To: David Miller, Saeed Mahameed
Cc: Linux Netdev List, Tonghao Zhang, Hadar Hen Zion
In-Reply-To: <1548718086-20924-1-git-send-email-xiangxia.m.yue@gmail.com>
On Tue, Jan 29, 2019 at 8:05 PM <xiangxia.m.yue@gmail.com> wrote:
>
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> When we offload tc filters to hardware, hardware flows can
> be updated when mac of encap destination ip is changed.
> But we ignore one case, that the mac of local encap ip can
> be changed too, so we should also update them.
>
> To fix it, add route_dev in mlx5e_encap_entry struct to save
> the local encap netdevice, and when mac changed, kernel will
> flush all the neighbour on the netdevice and send NETEVENT_NEIGH_UPDATE
> event. The mlx5 driver will delete the flows and add them when neighbour
> available again.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Cc: Hadar Hen Zion <hadarh@mellanox.com>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
This is good to go upstream, well done Tonghao!
^ permalink raw reply
* Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Li Yang @ 2019-01-29 19:50 UTC (permalink / raw)
To: Mathias Thore
Cc: Christophe Leroy, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David Gounaris, Joakim Tjernlund
In-Reply-To: <DM6PR10MB3721D7BA109A3823D9DACF1984970@DM6PR10MB3721.namprd10.prod.outlook.com>
On Tue, Jan 29, 2019 at 2:09 AM Mathias Thore
<Mathias.Thore@infinera.com> wrote:
>
> Is there a scenario where we are clearing the TX ring but don't want to reset the BQL TX queue?
Right now the function is also used on interface open/close, driver
removal and driver resumption besides the timeout situation. I think
the reseting BQL queue is either not neccessary or already called
explicitly for the other scenarios.
>
> I think it makes sense to keep it in ucc_geth_free_tx since the reason it is needed isn't the timeout per se, but rather the clearing of the TX ring. This way, it will be performed no matter why the driver ends up calling this function.
I don't see a consensus on when netdev_reset_queue() should be called
among existing drivers. Doing it on buffer ring cleanup probably can
be future-proofing. But if we want to use this approach, we can
remove the redundent netdev_reset_queue() calls in open/close
functions.
Regards,
Leo
>
> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Monday, 28 January 2019 22:37
> To: Mathias Thore <Mathias.Thore@infinera.com>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>; netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; David Gounaris <David.Gounaris@infinera.com>; Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Subject: Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
>
> On Mon, Jan 28, 2019 at 8:37 AM Mathias Thore <Mathias.Thore@infinera.com> wrote:
> >
> > Hi,
> >
> >
> > This is what we observed: there was a storm on the medium so that our controller could not do its TX, resulting in timeout. When timeout occurs, the driver clears all descriptors from the TX queue. The function called in this patch is used to reflect this clearing also in the BQL layer. Without it, the controller would get stuck, unable to perform TX, even several minutes after the storm had ended. Bringing the device down and then up again would solve the problem, but this patch also solves it automatically.
>
> The explanation makes sense. So this should only be required in the timeout scenario instead of other clean up scenarios like device shutdown? If so, it probably it will be better to be done in ucc_geth_timeout_work()?
>
> >
> >
> > Some other drivers do the same, for example e1000e driver calls netdev_reset_queue in its e1000_clean_tx_ring function. It is possible that other drivers should do the same; I have no way of verifying this.
> >
> >
> > Regards,
> >
> > Mathias
> >
> > --
> >
> >
> > From: Christophe Leroy <christophe.leroy@c-s.fr>
> > Sent: Monday, January 28, 2019 10:48 AM
> > To: Mathias Thore; leoyang.li@nxp.com; netdev@vger.kernel.org;
> > linuxppc-dev@lists.ozlabs.org; David Gounaris; Joakim Tjernlund
> > Subject: Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
> >
> >
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> >
> > Hi,
> >
> > Le 28/01/2019 à 10:07, Mathias Thore a écrit :
> > > After a timeout event caused by for example a broadcast storm, when
> > > the MAC and PHY are reset, the BQL TX queue needs to be reset as
> > > well. Otherwise, the device will exhibit severe performance issues
> > > even after the storm has ended.
> >
> > What are the symptomns ?
> >
> > Is this reset needed on any network driver in that case, or is it
> > something particular for the ucc_geth ?
> > For instance, the freescale fs_enet doesn't have that reset. Should it
> > have it too ?
> >
> > Christophe
> >
> > >
> > > Co-authored-by: David Gounaris <david.gounaris@infinera.com>
> > > Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
> > > ---
> > > drivers/net/ethernet/freescale/ucc_geth.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
> > > b/drivers/net/ethernet/freescale/ucc_geth.c
> > > index c3d539e209ed..eb3e65e8868f 100644
> > > --- a/drivers/net/ethernet/freescale/ucc_geth.c
> > > +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> > > @@ -1879,6 +1879,8 @@ static void ucc_geth_free_tx(struct ucc_geth_private *ugeth)
> > > u16 i, j;
> > > u8 __iomem *bd;
> > >
> > > + netdev_reset_queue(ugeth->ndev);
> > > +
> > > ug_info = ugeth->ug_info;
> > > uf_info = &ug_info->uf_info;
> > >
> > >
> >
^ permalink raw reply
* Re: [PATCH net] net: set default network namespace in init_dummy_netdev()
From: David Miller @ 2019-01-29 19:30 UTC (permalink / raw)
To: jelsasser
Cc: josh, ecree, ktkhai, jiri, petrm, edumazet, amritha.nambiar,
alexander.h.duyck, lirongqing, netdev, linux-kernel
In-Reply-To: <20190126223835.14613-1-jelsasser@appneta.com>
From: Josh Elsasser <jelsasser@appneta.com>
Date: Sat, 26 Jan 2019 14:38:33 -0800
> Assign a default net namespace to netdevs created by init_dummy_netdev().
> Fixes a NULL pointer dereference caused by busy-polling a socket bound to
> an iwlwifi wireless device, which bumps the per-net BUSYPOLLRXPACKETS stat
> if napi_poll() received packets:
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000190
> IP: napi_busy_loop+0xd6/0x200
> Call Trace:
> sock_poll+0x5e/0x80
> do_sys_poll+0x324/0x5a0
> SyS_poll+0x6c/0xf0
> do_syscall_64+0x6b/0x1f0
> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>
> Fixes: 7db6b048da3b ("net: Commonize busy polling code to focus on napi_id instead of socket")
> Signed-off-by: Josh Elsasser <jelsasser@appneta.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v4 4/4] can: tcan4x5x: Add tcan4x5x driver to the kernel
From: Dan Murphy @ 2019-01-29 19:27 UTC (permalink / raw)
To: Wolfgang Grandegger, mkl, davem, b29396; +Cc: linux-can, netdev, linux-kernel
In-Reply-To: <037720c9-4846-eb11-1d6a-b99d647d21d6@grandegger.com>
Wolfgang
Sorry for the late reply
On 1/22/19 4:03 AM, Wolfgang Grandegger wrote:
> Hello,
>
> Am 17.01.19 um 21:06 schrieb Dan Murphy:
>> Add the TCAN4x5x SPI CAN driver. This device
>> uses the Bosch MCAN IP core along with a SPI
>> interface map. Leverage the MCAN common core
>> code to manage the MCAN IP.
>>
>> This device has a special method to indicate a
>> write/read operation on the data payload.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> drivers/net/can/m_can/Kconfig | 6 +
>> drivers/net/can/m_can/tcan4x5x.c | 529 +++++++++++++++++++++++++++++++
>> 2 files changed, 535 insertions(+)
>> create mode 100644 drivers/net/can/m_can/tcan4x5x.c
>>
>> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
>> index b1a9358b7660..b38959b3b8f1 100644
>> --- a/drivers/net/can/m_can/Kconfig
>> +++ b/drivers/net/can/m_can/Kconfig
>> @@ -15,3 +15,9 @@ config CAN_M_CAN_PLATFORM
>> tristate "Bosch M_CAN devices"
>> ---help---
>> Say Y here if you want to support for Bosch M_CAN controller.
>> +
>> +config CAN_M_CAN_TCAN4X5X
>> + depends on CAN_M_CAN
>> + tristate "TCAN4X5X M_CAN device"
>> + ---help---
>> + Say Y here if you want to support for TI M_CAN controller.
>> diff --git a/drivers/net/can/m_can/tcan4x5x.c b/drivers/net/can/m_can/tcan4x5x.c
>> new file mode 100644
>> index 000000000000..3cd6cd5052b6
>> --- /dev/null
>> +++ b/drivers/net/can/m_can/tcan4x5x.c
>> @@ -0,0 +1,529 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// SPI to CAN driver for the Texas Instruments TCAN4x5x
>> +// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
>> +
>> +#include <linux/regmap.h>
>> +#include <linux/spi/spi.h>
>> +
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/gpio/consumer.h>
>> +
>> +#include "m_can_platform.h"
>> +
>> +#define DEVICE_NAME "tcan4x5x"
>> +#define TCAN4X5X_EXT_CLK_DEF 40000000
>> +
>> +#define TCAN4X5X_DEV_ID0 0x00
>> +#define TCAN4X5X_DEV_ID1 0x04
>> +#define TCAN4X5X_REV 0x08
>> +#define TCAN4X5X_STATUS 0x0C
>> +#define TCAN4X5X_ERROR_STATUS 0x10
>> +#define TCAN4X5X_CONTROL 0x14
>> +
>> +#define TCAN4X5X_CONFIG 0x800
>> +#define TCAN4X5X_TS_PRESCALE 0x804
>> +#define TCAN4X5X_TEST_REG 0x808
>> +#define TCAN4X5X_INT_FLAGS 0x820
>> +#define TCAN4X5X_MCAN_INT_REG 0x824
>> +#define TCAN4X5X_INT_EN 0x830
>> +
>> +
>> +/* Interrupt bits */
>> +#define TCAN4X5X_CANBUSTERMOPEN_INT_EN BIT(30)
>> +#define TCAN4X5X_CANHCANL_INT_EN BIT(29)
>> +#define TCAN4X5X_CANHBAT_INT_EN BIT(28)
>> +#define TCAN4X5X_CANLGND_INT_EN BIT(27)
>> +#define TCAN4X5X_CANBUSOPEN_INT_EN BIT(26)
>> +#define TCAN4X5X_CANBUSGND_INT_EN BIT(25)
>> +#define TCAN4X5X_CANBUSBAT_INT_EN BIT(24)
>> +#define TCAN4X5X_UVSUP_INT_EN BIT(22)
>> +#define TCAN4X5X_UVIO_INT_EN BIT(21)
>> +#define TCAN4X5X_TSD_INT_EN BIT(19)
>> +#define TCAN4X5X_ECCERR_INT_EN BIT(16)
>> +#define TCAN4X5X_CANINT_INT_EN BIT(15)
>> +#define TCAN4X5X_LWU_INT_EN BIT(14)
>> +#define TCAN4X5X_CANSLNT_INT_EN BIT(10)
>> +#define TCAN4X5X_CANDOM_INT_EN BIT(8)
>> +#define TCAN4X5X_CANBUS_ERR_INT_EN BIT(5)
>> +#define TCAN4X5X_BUS_FAULT BIT(4)
>> +#define TCAN4X5X_MCAN_INT BIT(1)
>> +#define TCAN4X5X_ENABLE_TCAN_INT (TCAN4X5X_MCAN_INT | \
>> + TCAN4X5X_BUS_FAULT | \
>> + TCAN4X5X_CANBUS_ERR_INT_EN | \
>> + TCAN4X5X_CANINT_INT_EN)
>> +
>> +/* MCAN Interrupt bits */
>> +#define TCAN4X5X_MCAN_IR_ARA BIT(29)
>> +#define TCAN4X5X_MCAN_IR_PED BIT(28)
>> +#define TCAN4X5X_MCAN_IR_PEA BIT(27)
>> +#define TCAN4X5X_MCAN_IR_WD BIT(26)
>> +#define TCAN4X5X_MCAN_IR_BO BIT(25)
>> +#define TCAN4X5X_MCAN_IR_EW BIT(24)
>> +#define TCAN4X5X_MCAN_IR_EP BIT(23)
>> +#define TCAN4X5X_MCAN_IR_ELO BIT(22)
>> +#define TCAN4X5X_MCAN_IR_BEU BIT(21)
>> +#define TCAN4X5X_MCAN_IR_BEC BIT(20)
>> +#define TCAN4X5X_MCAN_IR_DRX BIT(19)
>> +#define TCAN4X5X_MCAN_IR_TOO BIT(18)
>> +#define TCAN4X5X_MCAN_IR_MRAF BIT(17)
>> +#define TCAN4X5X_MCAN_IR_TSW BIT(16)
>> +#define TCAN4X5X_MCAN_IR_TEFL BIT(15)
>> +#define TCAN4X5X_MCAN_IR_TEFF BIT(14)
>> +#define TCAN4X5X_MCAN_IR_TEFW BIT(13)
>> +#define TCAN4X5X_MCAN_IR_TEFN BIT(12)
>> +#define TCAN4X5X_MCAN_IR_TFE BIT(11)
>> +#define TCAN4X5X_MCAN_IR_TCF BIT(10)
>> +#define TCAN4X5X_MCAN_IR_TC BIT(9)
>> +#define TCAN4X5X_MCAN_IR_HPM BIT(8)
>> +#define TCAN4X5X_MCAN_IR_RF1L BIT(7)
>> +#define TCAN4X5X_MCAN_IR_RF1F BIT(6)
>> +#define TCAN4X5X_MCAN_IR_RF1W BIT(5)
>> +#define TCAN4X5X_MCAN_IR_RF1N BIT(4)
>> +#define TCAN4X5X_MCAN_IR_RF0L BIT(3)
>> +#define TCAN4X5X_MCAN_IR_RF0F BIT(2)
>> +#define TCAN4X5X_MCAN_IR_RF0W BIT(1)
>> +#define TCAN4X5X_MCAN_IR_RF0N BIT(0)
>
> These bits are already defined in the common header file.
>
These are TCAN specific interrupt enable bits there are not in the Bosch register set
>> +#define TCAN4X5X_ENABLE_MCAN_INT (TCAN4X5X_MCAN_IR_TC | \
>> + TCAN4X5X_MCAN_IR_RF0N | \
>> + TCAN4X5X_MCAN_IR_RF1N | \
>> + TCAN4X5X_MCAN_IR_RF0F | \
>> + TCAN4X5X_MCAN_IR_RF1F)
>> +#define TCAN4X5X_MRAM_START 0x8000
>> +#define TCAN4X5X_MCAN_OFFSET 0x1000
>> +#define TCAN4X5X_MAX_REGISTER 0x8fff
>> +
>> +#define TCAN4X5X_CLEAR_ALL_INT 0xffffffff
>> +#define TCAN4X5X_SET_ALL_INT 0xffffffff
>> +
>> +#define TCAN4X5X_WRITE_CMD (0x61 << 24)
>> +#define TCAN4X5X_READ_CMD (0x41 << 24)
>> +
>> +#define TCAN4X5X_MODE_SEL_MASK (BIT(7) | BIT(6))
>> +#define TCAN4X5X_MODE_SLEEP 0x00
>> +#define TCAN4X5X_MODE_STANDBY BIT(6)
>> +#define TCAN4X5X_MODE_NORMAL BIT(7)
>> +
>> +#define TCAN4X5X_SW_RESET BIT(2)
>> +
>> +#define TCAN4X5X_MCAN_CONFIGURED BIT(5)
>> +#define TCAN4X5X_WATCHDOG_EN BIT(3)
>> +#define TCAN4X5X_WD_60_MS_TIMER 0
>> +#define TCAN4X5X_WD_600_MS_TIMER BIT(28)
>> +#define TCAN4X5X_WD_3_S_TIMER BIT(29)
>> +#define TCAN4X5X_WD_6_S_TIMER (BIT(28) | BIT(29))
>> +
>> +struct tcan4x5x_priv {
>> + struct regmap *regmap;
>> + struct spi_device *spi;
>> + struct mutex tcan4x5x_lock; /* SPI device lock */
>> +
>> + struct m_can_classdev *mcan_dev;
>> +
>> + struct gpio_desc *reset_gpio;
>> + struct gpio_desc *interrupt_gpio;
>> + struct gpio_desc *device_wake_gpio;
>> + struct gpio_desc *device_state_gpio;
>> + struct regulator *power;
>> +
>> + /* Register based ip */
>> + int mram_start;
>> + int reg_offset;
>> +};
>> +
>> +static struct can_bittiming_const tcan4x5x_bittiming_const = {
>> + .name = DEVICE_NAME,
>> + .tseg1_min = 2,
>> + .tseg1_max = 31,
>> + .tseg2_min = 2,
>> + .tseg2_max = 16,
>> + .sjw_max = 16,
>> + .brp_min = 1,
>> + .brp_max = 32,
>> + .brp_inc = 1,
>> +};
>> +
>> +static struct can_bittiming_const tcan4x5x_data_bittiming_const = {
>> + .name = DEVICE_NAME,
>> + .tseg1_min = 1,
>> + .tseg1_max = 32,
>> + .tseg2_min = 1,
>> + .tseg2_max = 16,
>> + .sjw_max = 16,
>> + .brp_min = 1,
>> + .brp_max = 32,
>> + .brp_inc = 1,
>> +};
>> +
>> +static void tcan4x5x_check_wake(struct tcan4x5x_priv *priv)
>> +{
>> + int wake_state = 0;
>> +
>> + if (priv->device_state_gpio)
>> + wake_state = gpiod_get_value(priv->device_state_gpio);
>> +
>> + if (priv->device_wake_gpio && wake_state) {
>> + gpiod_set_value(priv->device_wake_gpio, 1);
>> + udelay(100);
>> + gpiod_set_value(priv->device_wake_gpio, 0);
>> + udelay(100);
>> + gpiod_set_value(priv->device_wake_gpio, 1);
>> + }
>> +}
>> +
>> +static int regmap_spi_gather_write(void *context, const void *reg,
>> + size_t reg_len, const void *val,
>> + size_t val_len)
>> +{
>> + struct device *dev = context;
>> + struct spi_device *spi = to_spi_device(dev);
>> + struct spi_message m;
>> + u32 addr;
>> + struct spi_transfer t[2] = {{ .tx_buf = &addr, .len = reg_len, .cs_change = 0,},
>> + { .tx_buf = val, .len = val_len, },};
>> +
>> + addr = TCAN4X5X_WRITE_CMD | (*((u16 *)reg) << 8) | val_len >> 3;
>> +
>> + spi_message_init(&m);
>> + spi_message_add_tail(&t[0], &m);
>> + spi_message_add_tail(&t[1], &m);
>> +
>> + return spi_sync(spi, &m);
>> +}
>> +
>> +static int tcan4x5x_regmap_write(void *context, const void *data, size_t count)
>> +{
>> + u16 *reg = (u16 *)(data);
>> + const u32 *val = data + 4;
>> +
>> + return regmap_spi_gather_write(context, reg, 4, val, count);
>> +}
>> +
>> +static int regmap_spi_async_write(void *context,
>> + const void *reg, size_t reg_len,
>> + const void *val, size_t val_len,
>> + struct regmap_async *a)
>> +{
>> + return -ENOTSUPP;
>> +}
>> +
>> +static struct regmap_async *regmap_spi_async_alloc(void)
>> +{
>> + return NULL;
>> +}
>> +
>> +static int tcan4x5x_regmap_read(void *context,
>> + const void *reg, size_t reg_size,
>> + void *val, size_t val_size)
>> +{
>> + struct device *dev = context;
>> + struct spi_device *spi = to_spi_device(dev);
>> +
>> + u32 addr = TCAN4X5X_READ_CMD | (*((u16 *)reg) << 8) | val_size >> 2;
>> +
>> + return spi_write_then_read(spi, &addr, reg_size, (u32 *)val, val_size);
>> +}
>> +
>> +static struct regmap_bus tcan4x5x_bus = {
>> + .write = tcan4x5x_regmap_write,
>> + .gather_write = regmap_spi_gather_write,
>> + .async_write = regmap_spi_async_write,
>> + .async_alloc = regmap_spi_async_alloc,
>> + .read = tcan4x5x_regmap_read,
>> + .read_flag_mask = 0x00,
>> + .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
>> + .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
>> +};
>> +
>> +static u32 tcan4x5x_read_reg(struct m_can_classdev *m_can_class, int reg)
>> +{
>> + struct tcan4x5x_priv *priv = (struct tcan4x5x_priv *)m_can_class->device_data;
>> + u32 val;
>> +
>> + tcan4x5x_check_wake(priv);
>> +
>> + regmap_read(priv->regmap, priv->reg_offset + reg, &val);
>> +
>> + return val;
>> +}
>> +
>> +static u32 tcan4x5x_read_fifo(struct m_can_classdev *m_can_class,
>> + int addr_offset)
>> +{
>> + struct tcan4x5x_priv *priv = (struct tcan4x5x_priv *)m_can_class->device_data;
>> + u32 val;
>> +
>> + tcan4x5x_check_wake(priv);
>> +
>> + regmap_read(priv->regmap, priv->mram_start + addr_offset, &val);
>> +
>> + return val;
>> +}
>> +
>> +static int tcan4x5x_write_reg(struct m_can_classdev *m_can_class,
>> + int reg, int val)
>> +{
>> + struct tcan4x5x_priv *priv = (struct tcan4x5x_priv *)m_can_class->device_data;
>> +
>> + tcan4x5x_check_wake(priv);
>> +
>> + return regmap_write(priv->regmap, priv->reg_offset + reg, val);
>> +}
>> +
>> +static int tcan4x5x_write_fifo(struct m_can_classdev *m_can_class,
>> + int addr_offset, int val)
>> +{
>> + struct tcan4x5x_priv *priv = (struct tcan4x5x_priv *)m_can_class->device_data;
>> +
>> + tcan4x5x_check_wake(priv);
>> +
>> + return regmap_write(priv->regmap, priv->mram_start + addr_offset, val);
>> +}
>> +
>> +static int tcan4x5x_power_enable(struct regulator *reg, int enable)
>> +{
>> + if (IS_ERR_OR_NULL(reg))
>> + return 0;
>> +
>> + if (enable)
>> + return regulator_enable(reg);
>> + else
>> + return regulator_disable(reg);
>> +}
>> +
>> +static int tcan4x5x_write_tcan_reg(struct m_can_classdev *m_can_class,
>> + int reg, int val)
>> +{
>> + struct tcan4x5x_priv *priv = (struct tcan4x5x_priv *)m_can_class->device_data;
>> +
>> + tcan4x5x_check_wake(priv);
>> +
>> + return regmap_write(priv->regmap, reg, val);
>> +}
>> +
>> +static int tcan4x5x_clear_interrupts(struct m_can_classdev *class_dev)
>> +{
>> + struct tcan4x5x_priv *tcan4x5x = (struct tcan4x5x_priv *)class_dev->device_data;
>> + int ret;
>> +
>> + tcan4x5x_check_wake(tcan4x5x);
>> +
>> + ret = tcan4x5x_write_tcan_reg(class_dev, TCAN4X5X_STATUS,
>> + TCAN4X5X_CLEAR_ALL_INT);
>> + if (ret)
>> + return -EIO;
>> +
>> + ret = tcan4x5x_write_tcan_reg(class_dev, TCAN4X5X_MCAN_INT_REG,
>> + TCAN4X5X_ENABLE_MCAN_INT);
>> + if (ret)
>> + return -EIO;
>> +
>> + ret = tcan4x5x_write_tcan_reg(class_dev, TCAN4X5X_INT_FLAGS,
>> + TCAN4X5X_CLEAR_ALL_INT);
>> + if (ret)
>> + return -EIO;
>> +
>> +
>> + ret = tcan4x5x_write_tcan_reg(class_dev, TCAN4X5X_ERROR_STATUS,
>> + TCAN4X5X_CLEAR_ALL_INT);
>> + if (ret)
>> + return -EIO;
>> +
>> + return ret;
>> +}
>> +
>> +static int tcan4x5x_init(struct m_can_classdev *class_dev)
>> +{
>> + struct tcan4x5x_priv *tcan4x5x = (struct tcan4x5x_priv *)class_dev->device_data;
>> + int ret;
>> +
>> + tcan4x5x_check_wake(tcan4x5x);
>> +
>> + ret = tcan4x5x_clear_interrupts(class_dev);
>> + if (ret)
>> + return ret;
>> +
>> + ret = tcan4x5x_write_tcan_reg(class_dev, TCAN4X5X_INT_EN,
>> + TCAN4X5X_ENABLE_TCAN_INT);
>> + if (ret)
>> + return -EIO;
>> +
>> + ret = regmap_update_bits(tcan4x5x->regmap, TCAN4X5X_CONFIG,
>> + TCAN4X5X_MODE_SEL_MASK, TCAN4X5X_MODE_NORMAL);
>> + if (ret)
>> + return -EIO;
>> +
>> + /* Zero out the MCAN buffers */
>> + m_can_init_ram(class_dev);
>> +
>> + return ret;
>> +}
>> +
>> +static int tcan4x5x_parse_config(struct m_can_classdev *class_dev)
>> +{
>> + struct tcan4x5x_priv *tcan4x5x = (struct tcan4x5x_priv *)class_dev->device_data;
>> +
>> + tcan4x5x->reset_gpio = devm_gpiod_get_optional(class_dev->dev,
>> + "reset", GPIOD_OUT_LOW);
>> + if (IS_ERR(tcan4x5x->reset_gpio))
>> + tcan4x5x->reset_gpio = NULL;
>> +
>> + tcan4x5x->device_wake_gpio = devm_gpiod_get_optional(class_dev->dev,
>> + "device-wake",
>> + GPIOD_OUT_HIGH);
>> + if (IS_ERR(tcan4x5x->device_wake_gpio))
>> + tcan4x5x->device_wake_gpio = NULL;
>> +
>> + tcan4x5x->device_state_gpio = devm_gpiod_get_optional(class_dev->dev,
>> + "device-state",
>> + GPIOD_IN);
>> + if (IS_ERR(tcan4x5x->device_state_gpio))
>> + tcan4x5x->device_state_gpio = NULL;
>> +
>> + tcan4x5x->interrupt_gpio = devm_gpiod_get(class_dev->dev,
>> + "data-ready", GPIOD_IN);
>> + if (IS_ERR(tcan4x5x->interrupt_gpio)) {
>> + dev_err(class_dev->dev, "data-ready gpio not defined\n");
>> + return -EINVAL;
>> + }
>> +
>> + class_dev->net->irq = gpiod_to_irq(tcan4x5x->interrupt_gpio);
>> +
>> + tcan4x5x->power = devm_regulator_get_optional(class_dev->dev,
>> + "vsup");
>> + if (PTR_ERR(tcan4x5x->power) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct regmap_config tcan4x5x_regmap = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .cache_type = REGCACHE_NONE,
>> + .max_register = TCAN4X5X_MAX_REGISTER,
>> +};
>> +
>> +static int tcan4x5x_can_probe(struct spi_device *spi)
>> +{
>> + struct tcan4x5x_priv *priv;
>> + struct m_can_classdev *mcan_class;
>> + int freq, ret;
>> +
>> + mcan_class = m_can_core_allocate_dev(&spi->dev);
>> + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + mcan_class->device_data = priv;
>> +
>> + m_can_core_get_clocks(mcan_class);
>> + if (IS_ERR(mcan_class->cclk)) {
>> + dev_err(&spi->dev, "no CAN clock source defined\n");
>> + freq = TCAN4X5X_EXT_CLK_DEF;
>> + } else {
>> + freq = clk_get_rate(mcan_class->cclk);
>> + }
>> +
>> + /* Sanity check */
>> + if (freq < 20000000 || freq > TCAN4X5X_EXT_CLK_DEF)
>> + return -ERANGE;
>> +
>> + priv->reg_offset = TCAN4X5X_MCAN_OFFSET;
>> + priv->mram_start = TCAN4X5X_MRAM_START;
>> + priv->spi = spi;
>> + priv->mcan_dev = mcan_class;
>> +
>> + mcan_class->pm_clock_support = 0;
>> + mcan_class->can.clock.freq = freq;
>> + mcan_class->dev = &spi->dev;
>> +
>> + mcan_class->device_init = &tcan4x5x_init;
>> + mcan_class->read_reg = &tcan4x5x_read_reg;
>> + mcan_class->write_reg = &tcan4x5x_write_reg;
>> + mcan_class->write_fifo = &tcan4x5x_write_fifo;
>> + mcan_class->read_fifo = &tcan4x5x_read_fifo;
>> + mcan_class->clr_dev_interrupts = &tcan4x5x_clear_interrupts;
>> + mcan_class->is_peripherial = true;
>> +
>> + mcan_class->bit_timing = &tcan4x5x_bittiming_const;
>> + mcan_class->data_timing = &tcan4x5x_data_bittiming_const;
>> +
>> + spi_set_drvdata(spi, priv);
>> +
>> + ret = tcan4x5x_parse_config(mcan_class);
>> + if (ret)
>> + goto out_clk;
>> +
>> + /* Configure the SPI bus */
>> + spi->bits_per_word = 32;
>> + ret = spi_setup(spi);
>> + if (ret)
>> + goto out_clk;
>> +
>> + priv->regmap = devm_regmap_init(&spi->dev, &tcan4x5x_bus,
>> + &spi->dev, &tcan4x5x_regmap);
>> +
>> + mutex_init(&priv->tcan4x5x_lock);
>> +
>> + tcan4x5x_power_enable(priv->power, 1);
>> +
>> + ret = m_can_core_register(mcan_class);
>> + if (ret)
>> + goto reg_err;
>> +
>> + netdev_info(mcan_class->net, "TCAN4X5X successfully initialized.\n");
>> + return 0;
>> +
>> +reg_err:
>> + tcan4x5x_power_enable(priv->power, 0);
>> +out_clk:
>> + if (!IS_ERR(mcan_class->cclk)) {
>> + clk_disable_unprepare(mcan_class->cclk);
>> + clk_disable_unprepare(mcan_class->hclk);
>> + }
>> +
>> + dev_err(&spi->dev, "Probe failed, err=%d\n", -ret);
>> + return ret;
>> +}
>> +
>> +static int tcan4x5x_can_remove(struct spi_device *spi)
>> +{
>> + struct tcan4x5x_priv *priv = spi_get_drvdata(spi);
>> +
>> + tcan4x5x_power_enable(priv->power, 0);
>> +
>> + m_can_core_unregister(priv->mcan_dev);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id tcan4x5x_of_match[] = {
>> + { .compatible = "ti,tcan4x5x", },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, tcan4x5x_of_match);
>> +
>> +static const struct spi_device_id tcan4x5x_id_table[] = {
>> + {
>> + .name = "tcan4x5x",
>> + .driver_data = 0,
>> + },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(spi, tcan4x5x_id_table);
>> +
>> +static struct spi_driver tcan4x5x_can_driver = {
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .of_match_table = tcan4x5x_of_match,
>> + .pm = NULL,
>> + },
>> + .id_table = tcan4x5x_id_table,
>> + .probe = tcan4x5x_can_probe,
>> + .remove = tcan4x5x_can_remove,
>> +};
>> +module_spi_driver(tcan4x5x_can_driver);
>> +
>> +MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
>> +MODULE_DESCRIPTION("Texas Instruments TCAN4x5x CAN driver");
>> +MODULE_LICENSE("GPL v2");
>
> Curious to hear about the performance of M_CAN connected via SPI. Does
> it miss or drop messages?
>
Here is some cangen data we have.
We can probably speed it up but we want to get the code functional first.
/home/root/can/ip link set can0 up type can bitrate 1000000 dbitrate 10000000 fd on
root@am335x-evm:~/can# cat /proc/net/can/stats
5681 transmitted frames (TXF)
5681 received frames (RXF)
0 matched frames (RXMF)
0 % total match ratio (RXMR)
167 frames/s total tx rate (TXR)
167 frames/s total rx rate (RXR)
0 % current match ratio (CRXMR)
0 frames/s current tx rate (CTXR)
0 frames/s current rx rate (CRXR)
0 % max match ratio (MRXMR)
224 frames/s max tx rate (MTXR)
222 frames/s max rx rate (MRXR)
> Thanks for your patience,
>
> Wolfgang.
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: tc filter insertion rate degradation
From: Vlad Buslov @ 2019-01-29 19:22 UTC (permalink / raw)
To: Dennis Zhou
Cc: Eric Dumazet, Tejun Heo, Linux Kernel Network Developers,
Yevgeny Kliteynik, Yossef Efraim, Maor Gottlieb
In-Reply-To: <20190124172126.GA66944@dennisz-mbp.dhcp.thefacebook.com>
On Thu 24 Jan 2019 at 17:21, Dennis Zhou <dennis@kernel.org> wrote:
> Hi Vlad and Eric,
>
> On Tue, Jan 22, 2019 at 09:33:10AM -0800, Eric Dumazet wrote:
>> On Mon, Jan 21, 2019 at 3:24 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>> >
>> > Hi Eric,
>> >
>> > I've been investigating significant tc filter insertion rate degradation
>> > and it seems it is caused by your commit 001c96db0181 ("net: align
>> > gnet_stats_basic_cpu struct"). With this commit insertion rate is
>> > reduced from ~65k rules/sec to ~43k rules/sec when inserting 1m rules
>> > from file in tc batch mode on my machine.
>> >
>> > Tc perf profile indicates that pcpu allocator now consumes 2x CPU:
>> >
>> > 1) Before:
>> >
>> > Samples: 63K of event 'cycles:ppp', Event count (approx.): 48796480071
>> > Children Self Co Shared Object Symbol
>> > + 21.19% 3.38% tc [kernel.vmlinux] [k] pcpu_alloc
>> > + 3.45% 0.25% tc [kernel.vmlinux] [k] pcpu_alloc_area
>> >
>> > 2) After:
>> >
>> > Samples1: 92K of event 'cycles:ppp', Event count (approx.): 71446806550
>> > Children Self Co Shared Object Symbol
>> > + 44.67% 3.99% tc [kernel.vmlinux] [k] pcpu_alloc
>> > + 19.25% 0.22% tc [kernel.vmlinux] [k] pcpu_alloc_area
>> >
>> > It seems that it takes much more work for pcpu allocator to perform
>> > allocation with new stricter alignment requirements. Not sure if it is
>> > expected behavior or not in this case.
>> >
>> > Regards,
>> > Vlad
>
> Would you mind sharing a little more information with me:
> 1) output before and after a run of /sys/kernel/debug/percpu_stats
Hi Dennis,
Some of these files are quite large, so I put them to my Dropbox.
Output before:
Percpu Memory Statistics
Allocation Info:
----------------------------------------
unit_size : 262144
static_size : 139160
reserved_size : 8192
dyn_size : 28776
atom_size : 2097152
alloc_size : 2097152
Global Stats:
----------------------------------------
nr_alloc : 3343
nr_dealloc : 752
nr_cur_alloc : 2591
nr_max_alloc : 2598
nr_chunks : 3
nr_max_chunks : 3
min_alloc_size : 4
max_alloc_size : 8208
empty_pop_pages : 3
Per Chunk Stats:
----------------------------------------
Chunk: <- Reserved Chunk
nr_alloc : 5
max_alloc_size : 320
empty_pop_pages : 0
first_bit : 1002
free_bytes : 7448
contig_bytes : 7424
sum_frag : 24
max_frag : 24
cur_min_alloc : 16
cur_med_alloc : 64
cur_max_alloc : 320
Chunk: <- First Chunk
nr_alloc : 479
max_alloc_size : 8208
empty_pop_pages : 0
first_bit : 8192
free_bytes : 0
contig_bytes : 0
sum_frag : 0
max_frag : 0
cur_min_alloc : 4
cur_med_alloc : 24
cur_max_alloc : 8208
Chunk:
nr_alloc : 1925
max_alloc_size : 8208
empty_pop_pages : 0
first_bit : 63102
free_bytes : 852
contig_bytes : 12
sum_frag : 852
max_frag : 12
cur_min_alloc : 4
cur_med_alloc : 8
cur_max_alloc : 8208
Chunk:
nr_alloc : 182
max_alloc_size : 936
empty_pop_pages : 3
first_bit : 21
free_bytes : 256452
contig_bytes : 255120
sum_frag : 1332
max_frag : 368
cur_min_alloc : 8
cur_med_alloc : 20
cur_max_alloc : 320
After: https://www.dropbox.com/s/unyzhx4vgo2x30e/stats_after?dl=0
> 2) a full perf output
https://www.dropbox.com/s/isfcxca3npn5slx/perf.data?dl=0
> 3) a reproducer
$ sudo tc -b add.0
Example batch file: https://www.dropbox.com/s/ey7cbl5nwu5p0tg/add.0?dl=0
Thanks,
Vlad
^ permalink raw reply
* Re: [PATCH net] ixgbe: fix potential RX buffer starvation for AF_XDP
From: Jakub Kicinski @ 2019-01-29 19:14 UTC (permalink / raw)
To: Magnus Karlsson; +Cc: bjorn.topel, intel-wired-lan, netdev
In-Reply-To: <1548770630-16189-1-git-send-email-magnus.karlsson@intel.com>
On Tue, 29 Jan 2019 15:03:50 +0100, Magnus Karlsson wrote:
> When the RX rings are created they are also populated with buffers so
> that packets can be received. Usually these are kernel buffers, but
> for AF_XDP in zero-copy mode, these are user-space buffers and in this
> case the application might not have sent down any buffers to the
> driver at this point. And if no buffers are allocated at ring creation
> time, no packets can be received and no interupts will be generated so
> the napi poll function that allocates buffers to the rings will never
> get executed.
>
> To recitfy this, we kick the NAPI context of any queue with an
> attached AF_XDP zero-copy socket in two places in the code. Once after
> an XDP program has loaded and once after the umem is registered. This
> take care of both cases: XDP program gets loaded first then AF_XDP
> socket is created, and the reverse, AF_XDP socket is created first,
> then XDP program is loaded.
>
> Fixes: d0bcacd0a130 ("ixgbe: add AF_XDP zero-copy Rx support")
> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
I may not understand the problem fully, but isn't it kind of normal
that if you create a ring empty you'll never receive packets? And it
should be reasonably easy to catch while writing an app from scratch
(i.e. it behaves deterministically).
Plus user space can already do the kick manually: create the ring empty,
attach prog, put packets on the ring, and kick xmit - that would work,
no?
Putting the kick in ixgbe_xdp_setup() seems a tiny bit random to me,
but perhaps I'm not seeing the rationale clearly.
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Heiner Kallweit @ 2019-01-29 19:01 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190129153553.GL27062@torres.zugschlus.de>
Hi Marc,
the change to replace __rtl8169_set_wol(tp, 0) doesn't seem to be the right commit
because it was included in 4.18 already. And if you read the commit description you'll
see that it was replaced because it caused issues with certain boards. Having said that
it's not an option for us.
Still I'm struggling to see where the relevant difference between 4.18 and 4.19 is.
Especially as 4.19 and also later versions work perfectly fine here.
Can you in addition apply the following (again it may not apply cleanly) and provide
the results for 4.18 and 4.19?
And from today's run, can you provide the full dmesg output? I'd like to check
why the message was written on resume only.
Heiner
---
drivers/net/ethernet/realtek/r8169.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index bd26d3f2e..e9c37f10c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1414,6 +1414,8 @@ static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
wol->supported = WAKE_ANY;
wol->wolopts = tp->saved_wolopts;
rtl_unlock_work(tp);
+
+ pr_info("get_wol: 0x%08x\n", wol->wolopts);
}
static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
@@ -1491,6 +1493,8 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
struct rtl8169_private *tp = netdev_priv(dev);
struct device *d = tp_to_dev(tp);
+ pr_info("set_wol: 0x%08x\n", wol->wolopts);
+
if (wol->wolopts & ~WAKE_ANY)
return -EINVAL;
--
2.20.1
On 29.01.2019 16:35, Marc Haber wrote:
> Hi,
>
> after having a good night's sleep over that, it's obviously a merge
> commit which cannot easily be reverted. How would I continue after
> identifying a merge commit as the culprit?
>
> On Tue, Jan 29, 2019 at 08:32:53AM +0100, Marc Haber wrote:
>> According to bisect, the first bad commit is
>> 19725496da5602b401eae389736ab00d1817e264
>>
>> commit 19725496da5602b401eae389736ab00d1817e264
>> Merge: aea5f654e6b7 9981b4fb8684
>
> git diff aea5f654e6b7..19725496da5602b401eae389736ab00d1817e264,
> filtered for r8169 looks manageable:
>
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7396,8 +7396,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struc
> return rc;
> }
>
> - /* override BIOS settings, use userspace tools to enable WOL */
> - __rtl8169_set_wol(tp, 0);
> + tp->saved_wolopts = __rtl8169_get_wol(tp);
>
> mutex_init(&tp->wk.mutex);
> u64_stats_init(&tp->rx_stats.syncp);
>
> but the other one seems unmanageably big:
>
> [18/5009]mh@fan:~/linux/git/linux (master % u=) $ git diff 9981b4fb8684..19725496da5602b401eae389736ab00d1817e264 -- drivers/net/ethernet/realtek/r8169.c | diffstat
> r8169.c | 815 ++++++++++++++++++----------------------------------------------
> 1 file changed, 234 insertions(+), 581 deletions(-)
> [19/5009]mh@fan:~/linux/git/linux (master % u=) $
>
> -------
> But, indeed, adding the call to __rtl8169_set_wol(tp, 0) fixes the issue
> for me and the machine now wakes up from StR on a magic packet without
> having to go through strange ethtool motions.
> -------
>
> Would that code change be suitable for the official kernel cod?
>
> Greetings
> Marc
>
^ permalink raw reply related
* Re: [PATCHv2 net] sctp: check and update stream->out_curr when allocating stream_out
From: Tuxdriver @ 2019-01-29 18:58 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, Xin Long; +Cc: network dev, linux-sctp, davem
In-Reply-To: <20190129120531.GC10665@localhost.localdomain>
I was initially under the impression that with Kent's repost, the radixtree
(which is what I think you meant by rhashtables) updates would be merged
imminently, but that doesn't seem to be the case. I'd really like to know
what the hold up there is, as that patch seems to have been stalled for
months. I hate the notion of breaking the radixtree patch, but if it's
status is indeterminate, then, yes, we probably need to go with xins patch
for the short term, and let Kent fix it up in due course.
Neil
On January 29, 2019 1:06:33 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Thu, Nov 29, 2018 at 02:42:56PM +0800, Xin Long wrote:
>> Now when using stream reconfig to add out streams, stream->out
>> will get re-allocated, and all old streams' information will
>> be copied to the new ones and the old ones will be freed.
>>
>> So without stream->out_curr updated, next time when trying to
>> send from stream->out_curr stream, a panic would be caused.
>>
>> This patch is to check and update stream->out_curr when
>> allocating stream_out.
>>
>> v1->v2:
>> - define fa_index() to get elem index from stream->out_curr.
>>
>> Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
>> Reported-by: Ying Xu <yinxu@redhat.com>
>> Reported-by: syzbot+e33a3a138267ca119c7d@syzkaller.appspotmail.com
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>
> We are sort of mixing things up here. We have a bug on SCTP stack that
> triggers panics. As good practices recommends, the code should be as
> generic as possible and the SCTP-only was dropped in favor of a more
> generic one, fixing rhashtables instead. Okay. But then we discovered
> rhashtables are going away and we are now waiting on a restructing
> to fix the panic. That's not good, especially because it cannot and
> should not be backported into -stable trees.
>
> That said, we should not wait for the restructuring to _implicitly_
> fix the bug. We should pursuit both fixes here:
> - Apply this patch, to fix SCTP stack and allow it to be easily
> backportable.
> - Apply the generic fix, which is the restructuring, whenever it
> actually lands.
>
> Thoughts?
>
> Thanks,
> Marcelo
Sent with AquaMail for Android
https://www.mobisystems.com/aqua-mail
^ 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