* Re: Cavium Octeon III network driver.
From: Steven J. Hill @ 2018-04-16 15:29 UTC (permalink / raw)
To: Florian Fainelli, netdev
In-Reply-To: <cf2162fd-cf99-9ed9-a009-9fc47713d73f@gmail.com>
On 04/14/2018 07:08 PM, Florian Fainelli wrote:
>
> net-next tree is currently closed, but once it opens back up, you would
> likely want to resubmit those patches. Last I remember they were ready
> to go.
>
The announcement appears on this list for when it is open, correct?
^ permalink raw reply
* [PATCH net 0/2] tipc: Better check user provided attributes
From: Eric Dumazet @ 2018-04-16 15:29 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
syzbot reported a crash in __tipc_nl_net_set()
While fixing it, I also had to fix an old bug involving TIPC_NLA_NET_ADDR
Eric Dumazet (2):
tipc: add policy for TIPC_NLA_NET_ADDR
tipc: fix possible crash in __tipc_nl_net_set()
net/tipc/net.c | 2 ++
net/tipc/netlink.c | 5 ++++-
2 files changed, 6 insertions(+), 1 deletion(-)
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply
* [PATCH net 1/2] tipc: add policy for TIPC_NLA_NET_ADDR
From: Eric Dumazet @ 2018-04-16 15:29 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Jon Maloy, Ying Xue
In-Reply-To: <20180416152943.103989-1-edumazet@google.com>
Before syzbot/KMSAN bites, add the missing policy for TIPC_NLA_NET_ADDR
Fixes: 27c21416727a ("tipc: add net set to new netlink api")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: Ying Xue <ying.xue@windriver.com>
---
net/tipc/netlink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c
index b76f13f6fea10a53d00ed14a38cdf5cdf7afa44c..d4e0bbeee72793a060befaf8a9d0239731c0d48c 100644
--- a/net/tipc/netlink.c
+++ b/net/tipc/netlink.c
@@ -79,7 +79,8 @@ const struct nla_policy tipc_nl_sock_policy[TIPC_NLA_SOCK_MAX + 1] = {
const struct nla_policy tipc_nl_net_policy[TIPC_NLA_NET_MAX + 1] = {
[TIPC_NLA_NET_UNSPEC] = { .type = NLA_UNSPEC },
- [TIPC_NLA_NET_ID] = { .type = NLA_U32 }
+ [TIPC_NLA_NET_ID] = { .type = NLA_U32 },
+ [TIPC_NLA_NET_ADDR] = { .type = NLA_U32 },
};
const struct nla_policy tipc_nl_link_policy[TIPC_NLA_LINK_MAX + 1] = {
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 2/2] tipc: fix possible crash in __tipc_nl_net_set()
From: Eric Dumazet @ 2018-04-16 15:29 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Jon Maloy, Ying Xue
In-Reply-To: <20180416152943.103989-1-edumazet@google.com>
syzbot reported a crash in __tipc_nl_net_set() caused by NULL dereference.
We need to check that both TIPC_NLA_NET_NODEID and TIPC_NLA_NET_NODEID_W1
are present.
We also need to make sure userland provided u64 attributes.
Fixes: d50ccc2d3909 ("tipc: add 128-bit node identifier")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: Ying Xue <ying.xue@windriver.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/tipc/net.c | 2 ++
net/tipc/netlink.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/net/tipc/net.c b/net/tipc/net.c
index 856f9e97ea293210bea1d2003d2092482732ace9..4fbaa0464405370601cb2fd1dd3b03733836d342 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -252,6 +252,8 @@ int __tipc_nl_net_set(struct sk_buff *skb, struct genl_info *info)
u64 *w0 = (u64 *)&node_id[0];
u64 *w1 = (u64 *)&node_id[8];
+ if (!attrs[TIPC_NLA_NET_NODEID_W1])
+ return -EINVAL;
*w0 = nla_get_u64(attrs[TIPC_NLA_NET_NODEID]);
*w1 = nla_get_u64(attrs[TIPC_NLA_NET_NODEID_W1]);
tipc_net_init(net, node_id, 0);
diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c
index d4e0bbeee72793a060befaf8a9d0239731c0d48c..6ff2254088f647d4f7410c3335ccdae2e68ec522 100644
--- a/net/tipc/netlink.c
+++ b/net/tipc/netlink.c
@@ -81,6 +81,8 @@ const struct nla_policy tipc_nl_net_policy[TIPC_NLA_NET_MAX + 1] = {
[TIPC_NLA_NET_UNSPEC] = { .type = NLA_UNSPEC },
[TIPC_NLA_NET_ID] = { .type = NLA_U32 },
[TIPC_NLA_NET_ADDR] = { .type = NLA_U32 },
+ [TIPC_NLA_NET_NODEID] = { .type = NLA_U64 },
+ [TIPC_NLA_NET_NODEID_W1] = { .type = NLA_U64 },
};
const struct nla_policy tipc_nl_link_policy[TIPC_NLA_LINK_MAX + 1] = {
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust
From: Yafang Shao @ 2018-04-16 15:33 UTC (permalink / raw)
To: davem; +Cc: kuznet, yoshfuji, songliubraving, netdev, linux-kernel,
Yafang Shao
tcp_rcv_space_adjust is called every time data is copied to user space,
introducing a tcp tracepoint for which could show us when the packet is
copied to user.
This could help us figure out whether there's latency in user process.
When a tcp packet arrives, tcp_rcv_established() will be called and with
the existed tracepoint tcp_probe we could get the time when this packet
arrives.
Then this packet will be copied to user, and tcp_rcv_space_adjust will
be called and with this new introduced tracepoint we could get the time
when this packet is copied to user.
arrives time : user process time => latency caused by user
tcp_probe tcp_rcv_space_adjust
Hence in the prink message, sk is printed as a key to connect these two
tracepoints.
Maybe we could export sockfd in this new tracepoint as well, then we
could connect this new tracepoint with epoll/read/recv* tracepoint, and
finally that could show us the whole lifespan of this packet. But we
could also implement that with pid as these functions are executed in
process context.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/trace/events/tcp.h | 21 +++++++++++++++------
net/ipv4/tcp_input.c | 2 ++
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index 878b2be..65a6d22 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -146,10 +146,11 @@
sk->sk_v6_rcv_saddr, sk->sk_v6_daddr);
),
- TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c",
+ TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c sock=0x%p",
__entry->sport, __entry->dport,
__entry->saddr, __entry->daddr,
- __entry->saddr_v6, __entry->daddr_v6)
+ __entry->saddr_v6, __entry->daddr_v6,
+ __entry->skaddr)
);
DEFINE_EVENT(tcp_event_sk, tcp_receive_reset,
@@ -166,6 +167,13 @@
TP_ARGS(sk)
);
+DEFINE_EVENT(tcp_event_sk, tcp_rcv_space_adjust,
+
+ TP_PROTO(const struct sock *sk),
+
+ TP_ARGS(sk)
+);
+
TRACE_EVENT(tcp_set_state,
TP_PROTO(const struct sock *sk, const int oldstate, const int newstate),
@@ -265,6 +273,7 @@
TP_ARGS(sk, skb),
TP_STRUCT__entry(
+ __field(const void *, skaddr)
/* sockaddr_in6 is always bigger than sockaddr_in */
__array(__u8, saddr, sizeof(struct sockaddr_in6))
__array(__u8, daddr, sizeof(struct sockaddr_in6))
@@ -285,6 +294,8 @@
const struct tcp_sock *tp = tcp_sk(sk);
const struct inet_sock *inet = inet_sk(sk);
+ __entry->skaddr = sk;
+
memset(__entry->saddr, 0, sizeof(struct sockaddr_in6));
memset(__entry->daddr, 0, sizeof(struct sockaddr_in6));
@@ -305,13 +316,11 @@
__entry->srtt = tp->srtt_us >> 3;
),
- TP_printk("src=%pISpc dest=%pISpc mark=%#x length=%d snd_nxt=%#x "
- "snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u "
- "rcv_wnd=%u",
+ TP_printk("src=%pISpc dest=%pISpc mark=%#x length=%d snd_nxt=%#x snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u rcv_wnd=%u sock=0x%p",
__entry->saddr, __entry->daddr, __entry->mark,
__entry->length, __entry->snd_nxt, __entry->snd_una,
__entry->snd_cwnd, __entry->ssthresh, __entry->snd_wnd,
- __entry->srtt, __entry->rcv_wnd)
+ __entry->srtt, __entry->rcv_wnd, __entry->skaddr)
);
#endif /* _TRACE_TCP_H */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 367def6..4b4d6b9 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -582,6 +582,8 @@ void tcp_rcv_space_adjust(struct sock *sk)
u32 copied;
int time;
+ trace_tcp_rcv_space_adjust(sk);
+
tcp_mstamp_refresh(tp);
time = tcp_stamp_us_delta(tp->tcp_mstamp, tp->rcvq_space.time);
if (time < (tp->rcv_rtt_est.rtt_us >> 3) || tp->rcv_rtt_est.rtt_us == 0)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net] net: af_packet: fix race in PACKET_{R|T}X_RING
From: David Miller @ 2018-04-16 15:40 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20180416005204.86785-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 15 Apr 2018 17:52:04 -0700
> In order to remove the race caught by syzbot [1], we need
> to lock the socket before using po->tp_version as this could
> change under us otherwise.
>
> This means lock_sock() and release_sock() must be done by
> packet_set_ring() callers.
...
> Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
The locking in AF_PACKET is very unkind, as has been discussed
before. Good thing syzbot found this one.
The only other place we access po->tp_version asynchronously
is in the getsockopt() for statistics, and I guess that case
is OK.
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust
From: Eric Dumazet @ 2018-04-16 15:43 UTC (permalink / raw)
To: Yafang Shao, davem; +Cc: kuznet, yoshfuji, songliubraving, netdev, linux-kernel
In-Reply-To: <1523892818-12820-1-git-send-email-laoar.shao@gmail.com>
On 04/16/2018 08:33 AM, Yafang Shao wrote:
> tcp_rcv_space_adjust is called every time data is copied to user space,
> introducing a tcp tracepoint for which could show us when the packet is
> copied to user.
> This could help us figure out whether there's latency in user process.
>
> When a tcp packet arrives, tcp_rcv_established() will be called and with
> the existed tracepoint tcp_probe we could get the time when this packet
> arrives.
> Then this packet will be copied to user, and tcp_rcv_space_adjust will
> be called and with this new introduced tracepoint we could get the time
> when this packet is copied to user.
>
> arrives time : user process time => latency caused by user
> tcp_probe tcp_rcv_space_adjust
>
> Hence in the prink message, sk is printed as a key to connect these two
> tracepoints.
>
socket pointer is not a key.
TCP sockets can be reused pretty fast after free.
I suggest you go for cookie instead, this is an unique 64bit identifier.
( sock_gen_cookie() for details )
^ permalink raw reply
* Re: [Patch nf] nf_conntrack_extend: silent a memory leak warning
From: Pablo Neira Ayuso @ 2018-04-16 15:44 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, netfilter-devel, Jozsef Kadlecsik, Florian Westphal
In-Reply-To: <20180330202206.19565-1-xiyou.wangcong@gmail.com>
On Fri, Mar 30, 2018 at 01:22:06PM -0700, Cong Wang wrote:
> The following memory leak is false postive:
>
> unreferenced object 0xffff8f37f156fb38 (size 128):
> comm "softirq", pid 0, jiffies 4294899665 (age 11.292s)
> hex dump (first 32 bytes):
> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> 00 00 00 00 30 00 20 00 48 6b 6b 6b 6b 6b 6b 6b ....0. .Hkkkkkkk
> backtrace:
> [<000000004fda266a>] __kmalloc_track_caller+0x10d/0x141
> [<000000007b0a7e3c>] __krealloc+0x45/0x62
> [<00000000d08e0bfb>] nf_ct_ext_add+0xdc/0x133
> [<0000000099b47fd8>] init_conntrack+0x1b1/0x392
> [<0000000086dc36ec>] nf_conntrack_in+0x1ee/0x34b
> [<00000000940592de>] nf_hook_slow+0x36/0x95
> [<00000000d1bd4da7>] nf_hook.constprop.43+0x1c3/0x1dd
> [<00000000c3673266>] __ip_local_out+0xae/0xb4
> [<000000003e4192a6>] ip_local_out+0x17/0x33
> [<00000000b64356de>] igmp_ifc_timer_expire+0x23e/0x26f
> [<000000006a8f3032>] call_timer_fn+0x14c/0x2a5
> [<00000000650c1725>] __run_timers.part.34+0x150/0x182
> [<0000000090e6946e>] run_timer_softirq+0x2a/0x4c
> [<000000004d1e7293>] __do_softirq+0x1d1/0x3c2
> [<000000004643557d>] irq_exit+0x53/0xa2
> [<0000000029ddee8f>] smp_apic_timer_interrupt+0x22a/0x235
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/5] virtio: Add support for SCTP checksum offloading
From: Michael S. Tsirkin @ 2018-04-16 15:52 UTC (permalink / raw)
To: Vlad Yasevich
Cc: nhorman, netdev, virtualization, linux-sctp, Vladislav Yasevich
In-Reply-To: <f5655ab8-f24f-a5a5-d000-2bbb90ecc552@redhat.com>
On Mon, Apr 16, 2018 at 09:45:48AM -0400, Vlad Yasevich wrote:
> On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote:
> > On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote:
> >> To support SCTP checksum offloading, we need to add a new feature
> >> to virtio_net, so we can negotiate support between the hypervisor
> >> and the guest.
> >>
> >> The signalling to the guest that an alternate checksum needs to
> >> be used is done via a new flag in the virtio_net_hdr. If the
> >> flag is set, the host will know to perform an alternate checksum
> >> calculation, which right now is only CRC32c.
> >>
> >> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >> ---
> >> drivers/net/virtio_net.c | 11 ++++++++---
> >> include/linux/virtio_net.h | 6 ++++++
> >> include/uapi/linux/virtio_net.h | 2 ++
Could you pls include a virtio TC mailing list on uapi changes?
> >> 3 files changed, 16 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> >> index 7b187ec..b601294 100644
> >> --- a/drivers/net/virtio_net.c
> >> +++ b/drivers/net/virtio_net.c
> >> @@ -2724,9 +2724,14 @@ static int virtnet_probe(struct virtio_device *vdev)
> >> /* Do we support "hardware" checksums? */
> >> if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
> >> /* This opens up the world of extra features. */
> >> - dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> >> + netdev_features_t sctp = 0;
> >> +
> >> + if (virtio_has_feature(vdev, VIRTIO_NET_F_SCTP_CSUM))
> >> + sctp |= NETIF_F_SCTP_CRC;
> >> +
> >> + dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
> >> if (csum)
> >> - dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> >> + dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
> >>
> >> if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
> >> dev->hw_features |= NETIF_F_TSO
> >> @@ -2952,7 +2957,7 @@ static struct virtio_device_id id_table[] = {
> >> };
> >>
> >> #define VIRTNET_FEATURES \
> >> - VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
> >> + VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, VIRTIO_NET_F_SCTP_CSUM, \
> >> VIRTIO_NET_F_MAC, \
> >> VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6, \
> >> VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6, \
> >> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> >> index f144216..2e7a64a 100644
> >> --- a/include/linux/virtio_net.h
> >> +++ b/include/linux/virtio_net.h
> >> @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> >>
> >> if (!skb_partial_csum_set(skb, start, off))
> >> return -EINVAL;
> >> +
> >> + if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
> >> + skb->csum_not_inet = 1;
> >> }
> >>
> >> if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> >> @@ -96,6 +99,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> >> hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> >> } /* else everything is zero */
> >>
> >> + if (skb->csum_not_inet)
> >> + hdr->flags &= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
> >> +
> >> return 0;
> >> }
> >>
> >> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> >> index 5de6ed3..3f279c8 100644
> >> --- a/include/uapi/linux/virtio_net.h
> >> +++ b/include/uapi/linux/virtio_net.h
> >> @@ -36,6 +36,7 @@
> >> #define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial csum */
> >> #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Dynamic offload configuration. */
> >> #define VIRTIO_NET_F_MTU 3 /* Initial MTU advice */
> >> +#define VIRTIO_NET_F_SCTP_CSUM 4 /* SCTP checksum offload support */
> >> #define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
> >> #define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
> >> #define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
> >
> > Is this a guest or a host checksum? We should differenciate between the
> > two.
>
> I suppose this is HOST checksum, since it behaves like VIRTIO_NET_F_CSUM only for
> SCTP. I couldn't find the use for the GUEST side flag, since there technically
> isn't any validations and there is no additional mappings from VIRTIO flag to a
> NETIF flag.
>
> If the feature is negotiated, the guest ends up generating partially check-summed
> packets, and the host turns on appropriate flags on it's side. The host will
> also make sure the checksum if fixed up if the guest doesn't support it.
> So 1 flag is currently all that is needed.
>
> -vlad
Fine, but let's include HOST in there to make things clear.
Also I think we should use a high flag, like 62.
> >
> >
> >> @@ -101,6 +102,7 @@ struct virtio_net_config {
> >> struct virtio_net_hdr_v1 {
> >> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
> >> #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
> >> +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET 4 /* Checksum is not inet */
> >> __u8 flags;
> >> #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
> >> #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
> >> --
> >> 2.9.5
^ permalink raw reply
* [PATCH] ipv6: remove unnecessary check in addrconf_prefix_rcv_add_addr()
From: Lorenzo Bianconi @ 2018-04-16 15:52 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <cover.1523893788.git.lorenzo.bianconi@redhat.com>
Remove unnecessary check on update_lft variable in
addrconf_prefix_rcv_add_addr routine since it is always set to 0.
Moreover remove update_lft re-initialization to 0
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
net/ipv6/addrconf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index dffa38004c13..b2c0175125db 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2529,7 +2529,6 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
if (IS_ERR_OR_NULL(ifp))
return -1;
- update_lft = 0;
create = 1;
spin_lock_bh(&ifp->lock);
ifp->flags |= IFA_F_MANAGETEMPADDR;
@@ -2551,7 +2550,7 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
stored_lft = ifp->valid_lft - (now - ifp->tstamp) / HZ;
else
stored_lft = 0;
- if (!update_lft && !create && stored_lft) {
+ if (!create && stored_lft) {
const u32 minimum_lft = min_t(u32,
stored_lft, MIN_VALID_LIFETIME);
valid_lft = max(valid_lft, minimum_lft);
--
2.14.3
^ permalink raw reply related
* Re: Cavium Octeon III network driver.
From: Florian Fainelli @ 2018-04-16 15:53 UTC (permalink / raw)
To: Steven J. Hill, netdev
In-Reply-To: <af781f7a-c38c-9f1d-f3b7-b5ad5a667ccf@cavium.com>
On 04/16/2018 08:29 AM, Steven J. Hill wrote:
> On 04/14/2018 07:08 PM, Florian Fainelli wrote:
>>
>> net-next tree is currently closed, but once it opens back up, you would
>> likely want to resubmit those patches. Last I remember they were ready
>> to go.
>>
> The announcement appears on this list for when it is open, correct?
Correct, and the announcement was just made that net-next is open.
--
Florian
^ permalink raw reply
* Re: [PATCH] ipv6: remove unnecessary check in addrconf_prefix_rcv_add_addr()
From: Lorenzo Bianconi @ 2018-04-16 15:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <cd402c41ec4a3fb61702ae00115e54cfada4ba1d.1523893788.git.lorenzo.bianconi@redhat.com>
> Remove unnecessary check on update_lft variable in
> addrconf_prefix_rcv_add_addr routine since it is always set to 0.
> Moreover remove update_lft re-initialization to 0
>
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> ---
> net/ipv6/addrconf.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index dffa38004c13..b2c0175125db 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2529,7 +2529,6 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
> if (IS_ERR_OR_NULL(ifp))
> return -1;
>
> - update_lft = 0;
> create = 1;
> spin_lock_bh(&ifp->lock);
> ifp->flags |= IFA_F_MANAGETEMPADDR;
> @@ -2551,7 +2550,7 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
> stored_lft = ifp->valid_lft - (now - ifp->tstamp) / HZ;
> else
> stored_lft = 0;
> - if (!update_lft && !create && stored_lft) {
> + if (!create && stored_lft) {
> const u32 minimum_lft = min_t(u32,
> stored_lft, MIN_VALID_LIFETIME);
> valid_lft = max(valid_lft, minimum_lft);
> --
> 2.14.3
>
I forgot 'net-next' tag in the subject. Dave should I send a v2?
Regards,
Lorenzo
^ permalink raw reply
* BUG: DSA blocks (some?) multicast traffic
From: Russell King - ARM Linux @ 2018-04-16 16:00 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot; +Cc: netdev
Hi,
Yesterday, I noticed that one of my platforms had become unreachable
over IPv6. This platform is connected to a Clearfog, which uses
the Marvell 88e6176 switch.
The setup is:
(rest of network)
| | | | | | |
Source ---- Netgear switch ---- Clearfog switch ---- Target
^ ^ ^
lan1 lan5 eth2
port 4 port 0
Both the source and target could ping the IPv6 link-local address on
the clearfog, and IPv4 traffic was fine.
The source was attempting to ping the target, and the target had been
attempting to mount a NFS share over IPv6 (and failing.)
Statistics from the Clearfog switch - port 0 is the target, port 4 is
the netgear switch, port 5 is the CPU port:
Statistic Port 0 Port 1 Port 2 Port 3 Port 4 Port 5 Port 6
in_multicasts: 27670 0 0 14552 78196 1674 0
out_multicasts: 439 0 331 332 331 114860 334
As you can see, very few multicast packets have been sent out any of
the ports.
Running tcpdump on the source machine:
21:31:48.805654 xx:xx:xx:15:37:dd > 33:33:ff:00:00:05,
ethertype IPv6 (0x86dd), length 86:
fd8f:xxxx:xxxx:xxxx:222:68ff:fe15:37dd > ff02::1:ff00:5:
ICMP6, neighbor solicitation, who has
fd8f:xxxx:xxxx:xxxx:200:ff:fe00:5, length 32
tcpdump on the clearfog for port 4:
21:31:48.807640 xx:xx:xx:15:37:dd > 33:33:ff:00:00:05,
ethertype IPv6 (0x86dd), length 86:
fd8f:xxxx:xxxx:xxxx:222:68ff:fe15:37dd > ff02::1:ff00:5:
ICMP6, neighbor solicitation, who has
fd8f:xxxx:xxxx:xxxx:200:ff:fe00:5, length 32
The port connected to the target doesn't see these multicast messages
which are intended for it. However, I am able to see messages
multicasted from the target, which is trying to solicit a different
machine on my network:
21:33:22.394653 00:00:00:00:00:05 > 33:33:ff:10:1b:e6,
ethertype IPv6 (0x86dd), length 86:
fd8f:xxxx:xxxx:xxxx:200:ff:fe00:5 > ff02::1:ff10:1be6:
ICMP6, neighbor solicitation, who has
fd8f:xxxx:xxxx:xxxx:214:fdff:fe10:1be6, length 32
but these neighbour solicitations are also not forwarded to through
the switch to the rest of the network.
Tweaking the DSA switch port register 4 (which had a value of 0x0433)
to 0x043b resolved the issue - multicast traffic started to egress
these ports, and the neighbour solicitations then worked.
I thought maybe this was a 4.16 regression, but it seems my other
clearfog has a similar register setup, so I'm not sure. I'm pretty
sure that it used to work at some point, as I'm a heavy user of IPv6
internally, and I'm quite certain that I would have noticed a failure
such as this.
The setup on the target is eth2 is part of a Linux bridge device.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust
From: Yafang Shao @ 2018-04-16 16:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Alexey Kuznetsov, yoshfuji, Song Liu, netdev, LKML
In-Reply-To: <d2ab1647-c832-c982-5952-ab7a415f7c76@gmail.com>
On Mon, Apr 16, 2018 at 11:43 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 04/16/2018 08:33 AM, Yafang Shao wrote:
>> tcp_rcv_space_adjust is called every time data is copied to user space,
>> introducing a tcp tracepoint for which could show us when the packet is
>> copied to user.
>> This could help us figure out whether there's latency in user process.
>>
>> When a tcp packet arrives, tcp_rcv_established() will be called and with
>> the existed tracepoint tcp_probe we could get the time when this packet
>> arrives.
>> Then this packet will be copied to user, and tcp_rcv_space_adjust will
>> be called and with this new introduced tracepoint we could get the time
>> when this packet is copied to user.
>>
>> arrives time : user process time => latency caused by user
>> tcp_probe tcp_rcv_space_adjust
>>
>> Hence in the prink message, sk is printed as a key to connect these two
>> tracepoints.
>>
>
> socket pointer is not a key.
>
> TCP sockets can be reused pretty fast after free.
>
> I suggest you go for cookie instead, this is an unique 64bit identifier.
> ( sock_gen_cookie() for details )
>
>
Thanks for your explanation.
Will have a try.
Thanks
Yafang
^ permalink raw reply
* Re: XDP performance regression due to CONFIG_RETPOLINE Spectre V2
From: Alexander Duyck @ 2018-04-16 16:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jesper Dangaard Brouer, xdp-newbies@vger.kernel.org,
netdev@vger.kernel.org, Christoph Hellwig, David Woodhouse,
William Tu, Björn Töpel, Karlsson, Magnus,
Arnaldo Carvalho de Melo
In-Reply-To: <20180416122706.GA20624@infradead.org>
On Mon, Apr 16, 2018 at 5:27 AM, Christoph Hellwig <hch@infradead.org> wrote:
> Can you try the following hack which avoids indirect calls entirely
> for the fast path direct mapping case?
>
> ---
> From b256a008c1b305e6a1c2afe7c004c54ad2e96d4b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Mon, 16 Apr 2018 14:18:14 +0200
> Subject: dma-mapping: bypass dma_ops for direct mappings
>
> Reportedly the retpoline mitigation for spectre causes huge penalties
> for indirect function calls. This hack bypasses the dma_ops mechanism
> for simple direct mappings.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/device.h | 1 +
> include/linux/dma-mapping.h | 53 +++++++++++++++++++++++++++----------
> lib/dma-direct.c | 4 +--
> 3 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 0059b99e1f25..725eec4c6653 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -990,6 +990,7 @@ struct device {
> bool offline_disabled:1;
> bool offline:1;
> bool of_node_reused:1;
> + bool is_dma_direct:1;
> };
>
> static inline struct device *kobj_to_dev(struct kobject *kobj)
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index f8ab1c0f589e..c5d384ae25d6 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -223,6 +223,13 @@ static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
> }
> #endif
>
> +/* do not use directly! */
> +dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size, enum dma_data_direction dir,
> + unsigned long attrs);
> +int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir, unsigned long attrs);
> +
> static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
> size_t size,
> enum dma_data_direction dir,
> @@ -232,9 +239,13 @@ static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
> dma_addr_t addr;
>
> BUG_ON(!valid_dma_direction(dir));
> - addr = ops->map_page(dev, virt_to_page(ptr),
> - offset_in_page(ptr), size,
> - dir, attrs);
> + if (dev->is_dma_direct) {
> + addr = dma_direct_map_page(dev, virt_to_page(ptr),
> + offset_in_page(ptr), size, dir, attrs);
> + } else {
> + addr = ops->map_page(dev, virt_to_page(ptr),
> + offset_in_page(ptr), size, dir, attrs);
> + }
> debug_dma_map_page(dev, virt_to_page(ptr),
> offset_in_page(ptr), size,
> dir, addr, true);
I'm not sure if I am really a fan of trying to solve this in this way.
It seems like this is going to be optimizing the paths for one case at
the detriment of others. Historically mapping and unmapping has always
been expensive, especially in the case of IOMMU enabled environments.
I would much rather see us focus on having swiotlb_dma_ops replaced
with dma_direct_ops in the cases where the device can access all of
physical memory.
> @@ -249,7 +260,7 @@ static inline void dma_unmap_single_attrs(struct device *dev, dma_addr_t addr,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->unmap_page)
> + if (!dev->is_dma_direct && ops->unmap_page)
If I understand correctly this is only needed for the swiotlb case and
not the dma_direct case. It would make much more sense to just
overwrite the dev->dma_ops pointer with dma_direct_ops to address all
of the sync and unmap cases.
> ops->unmap_page(dev, addr, size, dir, attrs);
> debug_dma_unmap_page(dev, addr, size, dir, true);
> }
> @@ -266,7 +277,10 @@ static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
> int ents;
>
> BUG_ON(!valid_dma_direction(dir));
> - ents = ops->map_sg(dev, sg, nents, dir, attrs);
> + if (dev->is_dma_direct)
> + ents = dma_direct_map_sg(dev, sg, nents, dir, attrs);
> + else
> + ents = ops->map_sg(dev, sg, nents, dir, attrs);
> BUG_ON(ents < 0);
> debug_dma_map_sg(dev, sg, nents, ents, dir);
>
> @@ -281,7 +295,7 @@ static inline void dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sg
>
> BUG_ON(!valid_dma_direction(dir));
> debug_dma_unmap_sg(dev, sg, nents, dir);
> - if (ops->unmap_sg)
> + if (!dev->is_dma_direct && ops->unmap_sg)
> ops->unmap_sg(dev, sg, nents, dir, attrs);
> }
>
> @@ -295,7 +309,10 @@ static inline dma_addr_t dma_map_page_attrs(struct device *dev,
> dma_addr_t addr;
>
> BUG_ON(!valid_dma_direction(dir));
> - addr = ops->map_page(dev, page, offset, size, dir, attrs);
> + if (dev->is_dma_direct)
> + addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
> + else
> + addr = ops->map_page(dev, page, offset, size, dir, attrs);
> debug_dma_map_page(dev, page, offset, size, dir, addr, false);
>
> return addr;
> @@ -309,7 +326,7 @@ static inline void dma_unmap_page_attrs(struct device *dev,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->unmap_page)
> + if (!dev->is_dma_direct && ops->unmap_page)
> ops->unmap_page(dev, addr, size, dir, attrs);
> debug_dma_unmap_page(dev, addr, size, dir, false);
> }
> @@ -356,7 +373,7 @@ static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->sync_single_for_cpu)
> + if (!dev->is_dma_direct && ops->sync_single_for_cpu)
> ops->sync_single_for_cpu(dev, addr, size, dir);
> debug_dma_sync_single_for_cpu(dev, addr, size, dir);
> }
> @@ -368,7 +385,7 @@ static inline void dma_sync_single_for_device(struct device *dev,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->sync_single_for_device)
> + if (!dev->is_dma_direct && ops->sync_single_for_device)
> ops->sync_single_for_device(dev, addr, size, dir);
> debug_dma_sync_single_for_device(dev, addr, size, dir);
> }
> @@ -382,7 +399,7 @@ static inline void dma_sync_single_range_for_cpu(struct device *dev,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->sync_single_for_cpu)
> + if (!dev->is_dma_direct && ops->sync_single_for_cpu)
> ops->sync_single_for_cpu(dev, addr + offset, size, dir);
> debug_dma_sync_single_range_for_cpu(dev, addr, offset, size, dir);
> }
> @@ -396,7 +413,7 @@ static inline void dma_sync_single_range_for_device(struct device *dev,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->sync_single_for_device)
> + if (!dev->is_dma_direct && ops->sync_single_for_device)
> ops->sync_single_for_device(dev, addr + offset, size, dir);
> debug_dma_sync_single_range_for_device(dev, addr, offset, size, dir);
> }
> @@ -408,7 +425,7 @@ dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->sync_sg_for_cpu)
> + if (!dev->is_dma_direct && ops->sync_sg_for_cpu)
> ops->sync_sg_for_cpu(dev, sg, nelems, dir);
> debug_dma_sync_sg_for_cpu(dev, sg, nelems, dir);
> }
> @@ -420,7 +437,7 @@ dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> BUG_ON(!valid_dma_direction(dir));
> - if (ops->sync_sg_for_device)
> + if (!dev->is_dma_direct && ops->sync_sg_for_device)
> ops->sync_sg_for_device(dev, sg, nelems, dir);
> debug_dma_sync_sg_for_device(dev, sg, nelems, dir);
>
> @@ -600,6 +617,8 @@ static inline int dma_supported(struct device *dev, u64 mask)
> return ops->dma_supported(dev, mask);
> }
>
> +extern const struct dma_map_ops swiotlb_dma_ops;
> +
> #ifndef HAVE_ARCH_DMA_SET_MASK
> static inline int dma_set_mask(struct device *dev, u64 mask)
> {
> @@ -609,6 +628,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
> dma_check_mask(dev, mask);
>
> *dev->dma_mask = mask;
> + if (dev->dma_ops == &dma_direct_ops ||
> + (dev->dma_ops == &swiotlb_dma_ops &&
> + mask == DMA_BIT_MASK(64)))
> + dev->is_dma_direct = true;
> + else
> + dev->is_dma_direct = false;
So I am not sure this will work on x86. If I am not mistaken I believe
dev->dma_ops is normally not set and instead the default dma
operations are pulled via get_arch_dma_ops which returns the global
dma_ops pointer.
What you may want to consider as an alternative would be to look at
modifying drivers that are using the swiotlb so that you could just
overwrite the dev->dma_ops with the dma_direct_ops in the cases where
the hardware can support accessing all of physical hardware and where
we aren't forcing the use of the bounce buffers in the swiotlb.
Then for the above code you only have to worry about the map calls,
and you could just do a check against the dma_direct_ops pointer
instead of having to add a new flag.
> return 0;
> }
> #endif
> diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> index c0bba30fef0a..3deb8666974b 100644
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -120,7 +120,7 @@ void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
> free_pages((unsigned long)cpu_addr, page_order);
> }
>
> -static dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
> +dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
> unsigned long offset, size_t size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> @@ -131,7 +131,7 @@ static dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
> return dma_addr;
> }
>
> -static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
> +int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
> int nents, enum dma_data_direction dir, unsigned long attrs)
> {
> int i;
> --
> 2.17.0
>
>
^ permalink raw reply
* [PATCH net-next 1/1] tc-testing: add sample action tests
From: Roman Mashak @ 2018-04-16 16:06 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
.../tc-testing/tc-tests/actions/sample.json | 588 +++++++++++++++++++++
1 file changed, 588 insertions(+)
create mode 100644 tools/testing/selftests/tc-testing/tc-tests/actions/sample.json
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/sample.json b/tools/testing/selftests/tc-testing/tc-tests/actions/sample.json
new file mode 100644
index 000000000000..3aca33c00039
--- /dev/null
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/sample.json
@@ -0,0 +1,588 @@
+[
+ {
+ "id": "9784",
+ "name": "Add valid sample action with mandatory arguments",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 10 group 1 index 2",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 2",
+ "matchPattern": "action order [0-9]+: sample rate 1/10 group 1.*index 2 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "5c91",
+ "name": "Add valid sample action with mandatory arguments and continue control action",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 700 group 2 continue index 2",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 2",
+ "matchPattern": "action order [0-9]+: sample rate 1/700 group 2 continue.*index 2 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "334b",
+ "name": "Add valid sample action with mandatory arguments and drop control action",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 10000 group 11 drop index 22",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/10000 group 11 drop.*index 22 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "da69",
+ "name": "Add valid sample action with mandatory arguments and reclassify control action",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 20000 group 72 reclassify index 100",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/20000 group 72 reclassify.*index 100 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "13ce",
+ "name": "Add valid sample action with mandatory arguments and pipe control action",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 20 group 2 pipe index 100",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/20 group 2 pipe.*index 100 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "1886",
+ "name": "Add valid sample action with mandatory arguments and jump control action",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 700 group 25 jump 4 index 200",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 200",
+ "matchPattern": "action order [0-9]+: sample rate 1/700 group 25 jump 4.*index 200 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "b6d4",
+ "name": "Add sample action with mandatory arguments and invalid control action",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 200000 group 52 foo index 1",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/200000 group 52 foo.*index 1 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "a874",
+ "name": "Add invalid sample action without mandatory arguments",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample index 1",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample.*index 1 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "ac01",
+ "name": "Add invalid sample action without mandatory argument rate",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample group 10 index 1",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample.*group 10.*index 1 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "4203",
+ "name": "Add invalid sample action without mandatory argument group",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 100 index 10",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action sample index 10",
+ "matchPattern": "action order [0-9]+: sample rate 1/100.*index 10 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "14a7",
+ "name": "Add invalid sample action without mandatory argument group",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 100 index 10",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action sample index 10",
+ "matchPattern": "action order [0-9]+: sample rate 1/100.*index 10 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "8f2e",
+ "name": "Add valid sample action with trunc argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 1024 group 4 trunc 1024 index 10",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 10",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 4 trunc_size 1024 pipe.*index 10 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "45f8",
+ "name": "Add sample action with maximum rate argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 4294967295 group 4 index 10",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 10",
+ "matchPattern": "action order [0-9]+: sample rate 1/4294967295 group 4 pipe.*index 10 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "ad0c",
+ "name": "Add sample action with maximum trunc argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 16000 group 4 trunc 4294967295 index 10",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 10",
+ "matchPattern": "action order [0-9]+: sample rate 1/16000 group 4 trunc_size 4294967295 pipe.*index 10 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "83a9",
+ "name": "Add sample action with maximum group argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 4294 group 4294967295 index 1",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 1",
+ "matchPattern": "action order [0-9]+: sample rate 1/4294 group 4294967295 pipe.*index 1 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "ed27",
+ "name": "Add sample action with invalid rate argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 4294967296 group 4 index 10",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action sample index 10",
+ "matchPattern": "action order [0-9]+: sample rate 1/4294967296 group 4 pipe.*index 10 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "2eae",
+ "name": "Add sample action with invalid group argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 4098 group 5294967299 continue index 1",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action sample index 1",
+ "matchPattern": "action order [0-9]+: sample rate 1/4098 group 5294967299 continue.*index 1 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "6ff3",
+ "name": "Add sample action with invalid trunc size",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 1024 group 4 trunc 112233445566 index 11",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action sample index 11",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 4 trunc_size 112233445566.*index 11 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "2b2a",
+ "name": "Add sample action with invalid index",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 1024 group 4 index 5294967299",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action sample index 5294967299",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 4 pipe.*index 5294967299 ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "dee2",
+ "name": "Add sample action with maximum allowed index",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 1024 group 4 index 4294967295",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 4294967295",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 4 pipe.*index 4294967295 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "560e",
+ "name": "Add sample action with cookie",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action sample rate 1024 group 4 index 45 cookie aabbccdd",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action sample index 45",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 4 pipe.*index 45.*cookie aabbccdd",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "704a",
+ "name": "Replace existing sample action with new rate argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC actions add action sample rate 1024 group 4 index 4"
+ ],
+ "cmdUnderTest": "$TC actions replace action sample rate 2048 group 4 index 4",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/2048 group 4 pipe.*index 4",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "60eb",
+ "name": "Replace existing sample action with new group argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC actions add action sample rate 1024 group 4 index 4"
+ ],
+ "cmdUnderTest": "$TC actions replace action sample rate 1024 group 7 index 4",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 7 pipe.*index 4",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "2cce",
+ "name": "Replace existing sample action with new trunc argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC actions add action sample rate 1024 group 4 trunc 48 index 4"
+ ],
+ "cmdUnderTest": "$TC actions replace action sample rate 1024 group 7 trunc 64 index 4",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 7 trunc_size 64 pipe.*index 4",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ },
+ {
+ "id": "59d1",
+ "name": "Replace existing sample action with new control argument",
+ "category": [
+ "actions",
+ "sample"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action sample",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC actions add action sample rate 1024 group 4 reclassify index 4"
+ ],
+ "cmdUnderTest": "$TC actions replace action sample rate 1024 group 7 pipe index 4",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action sample",
+ "matchPattern": "action order [0-9]+: sample rate 1/1024 group 7 pipe.*index 4",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action sample"
+ ]
+ }
+]
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/1] net/mlx4_core: avoid resetting HCA when accessing an offline device
From: David Miller @ 2018-04-16 16:51 UTC (permalink / raw)
To: yanjun.zhu; +Cc: tariqt, netdev, linux-rdma, haakon.bugge
In-Reply-To: <1523840527-22746-1-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Sun, 15 Apr 2018 21:02:07 -0400
> While a faulty cable is used or HCA firmware error, HCA device will
> be offline. When the driver is accessing this offline device, the
> following call trace will pop out.
...
> In the above call trace, the function mlx4_cmd_poll calls the function
> mlx4_cmd_post to access the HCA while HCA is offline. Then mlx4_cmd_post
> returns an error -EIO. Per -EIO, the function mlx4_cmd_poll calls
> mlx4_cmd_reset_flow to reset HCA. And the above call trace pops out.
>
> This is not reasonable. Since HCA device is offline when it is being
> accessed, it should not be reset again.
>
> In this patch, since HCA is offline, the function mlx4_cmd_post returns
> an error -EINVAL. Per -EINVAL, the function mlx4_cmd_poll directly returns
> instead of resetting HCA.
>
> CC: Srinivas Eeda <srinivas.eeda@oracle.com>
> CC: Junxiao Bi <junxiao.bi@oracle.com>
> Suggested-by: Håkon Bugge <haakon.bugge@oracle.com>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Tariq, I'm assuming you'll take this in and send it to me later.
Thanks.
^ permalink raw reply
* Re: [PATCH net] net: Fix one possible memleak in ip_setup_cork
From: David Miller @ 2018-04-16 16:58 UTC (permalink / raw)
To: gfree.wind; +Cc: kuznet, netdev
In-Reply-To: <1523845005-6353-2-git-send-email-gfree.wind@vip.163.com>
From: gfree.wind@vip.163.com
Date: Mon, 16 Apr 2018 10:16:45 +0800
> From: Gao Feng <gfree.wind@vip.163.com>
>
> It would allocate memory in this function when the cork->opt is NULL. But
> the memory isn't freed if failed in the latter rt check, and return error
> directly. It causes the memleak if its caller is ip_make_skb which also
> doesn't free the cork->opt when meet a error.
>
> Now move the rt check ahead to avoid the memleak.
>
> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
Looks good, applied and queued up for -stable.
I guess in the other code paths, ip_flush_pending_frames() or similar
would clean up the in-sock cork information.
^ permalink raw reply
* Re: [PATCH] ipv6: remove unnecessary check in addrconf_prefix_rcv_add_addr()
From: David Miller @ 2018-04-16 17:00 UTC (permalink / raw)
To: lorenzo.bianconi; +Cc: netdev
In-Reply-To: <CAJ0CqmVBOk9rctqxoVEvO2yP_++yMDu7xpMYf-PRcqcJaQ=Zag@mail.gmail.com>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date: Mon, 16 Apr 2018 17:56:33 +0200
> I forgot 'net-next' tag in the subject. Dave should I send a v2?
Not necessary.
^ permalink raw reply
* Re: Stack smash error in latest version of iproute2's 'ip'
From: Stephen Hemminger @ 2018-04-16 17:00 UTC (permalink / raw)
To: Paul Claessen; +Cc: netdev
In-Reply-To: <1590297271.174659.1523897880294@email.1and1.com>
On Mon, 16 Apr 2018 12:58:00 -0400 (EDT)
Paul Claessen <paul@claessen.com> wrote:
> Greetings,
>
> I'm getting a "*** stack smashing detected ***: ip terminated" error when using 'ip macsec show'.
>
> This happens on Ubuntu 16.04.4 (Xemian) on an AMD64 PC.
> ip version is 180402
>
> Screen output:
>
> paul@paulux:~$ ip -V
> ip utility, iproute2-ss180402
>
> paul@paulux:~$ ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> link/ether 00:21:9b:49:5c:aa brd ff:ff:ff:ff:ff:ff
> 3: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
> link/ether a0:36:9f:20:37:fc brd ff:ff:ff:ff:ff:ff
> 4: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
> link/ether a0:36:9f:20:37:fe brd ff:ff:ff:ff:ff:ff
> 5: wlxf4ec38845800: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> link/ether f4:ec:38:84:58:00 brd ff:ff:ff:ff:ff:ff
> inet 10.205.213.28/8 brd 10.255.255.255 scope global dynamic wlxf4ec38845800
> valid_lft 59124sec preferred_lft 59124sec
> inet6 fe80::ea99:1f1b:9ff:1d57/64 scope link
> valid_lft forever preferred_lft forever
> 6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
> link/ether 02:42:76:15:77:09 brd ff:ff:ff:ff:ff:ff
> inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
> valid_lft forever preferred_lft forever
> 7: macsec0@enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1468 qdisc noqueue state UNKNOWN group default qlen 1000
> link/ether 00:21:9b:49:5c:aa brd ff:ff:ff:ff:ff:ff
> inet 192.168.100.1/24 scope global macsec0
> valid_lft forever preferred_lft forever
> inet6 fe80::221:9bff:fe49:5caa/64 scope link
> valid_lft forever preferred_lft forever
>
>
>
> paul@paulux:~$ ip macsec show
> 7: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
> cipher suite: GCM-AES-128, using ICV length 16
> TXSC: 000000005caa0001 on SA 0
> 0: PN 45547, state on, key 00000000000000000000000000000000
> RXSC: 00000000778c0001, state on
> 0: PN 3976, state on, key 01000000000000000000000000000000
> *** stack smashing detected ***: ip terminated
> Aborted (core dumped)
>
>
> Kind regards,
>
> ~ Paul Claessen
>
>
Probably something in the new code to do JSON output.
^ permalink raw reply
* Re: [PATCH net-next 1/5] virtio: Add support for SCTP checksum offloading
From: Michael S. Tsirkin @ 2018-04-16 17:07 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, virtualization, jasowang, nhorman,
Vladislav Yasevich
In-Reply-To: <20180402134006.10111-2-vyasevic@redhat.com>
On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote:
> To support SCTP checksum offloading, we need to add a new feature
> to virtio_net, so we can negotiate support between the hypervisor
> and the guest.
>
> The signalling to the guest that an alternate checksum needs to
> be used is done via a new flag in the virtio_net_hdr. If the
> flag is set, the host will know to perform an alternate checksum
> calculation, which right now is only CRC32c.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> drivers/net/virtio_net.c | 11 ++++++++---
> include/linux/virtio_net.h | 6 ++++++
> include/uapi/linux/virtio_net.h | 2 ++
> 3 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7b187ec..b601294 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2724,9 +2724,14 @@ static int virtnet_probe(struct virtio_device *vdev)
> /* Do we support "hardware" checksums? */
> if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
> /* This opens up the world of extra features. */
> - dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> + netdev_features_t sctp = 0;
> +
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_SCTP_CSUM))
> + sctp |= NETIF_F_SCTP_CRC;
> +
> + dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
> if (csum)
> - dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> + dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
>
> if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
> dev->hw_features |= NETIF_F_TSO
> @@ -2952,7 +2957,7 @@ static struct virtio_device_id id_table[] = {
> };
>
> #define VIRTNET_FEATURES \
> - VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
> + VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, VIRTIO_NET_F_SCTP_CSUM, \
> VIRTIO_NET_F_MAC, \
> VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6, \
> VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6, \
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index f144216..2e7a64a 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>
> if (!skb_partial_csum_set(skb, start, off))
> return -EINVAL;
> +
> + if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
> + skb->csum_not_inet = 1;
> }
>
> if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
Looks like we need a feature flag to tell host guest is able to handle this flag
in incoming packets ...
> @@ -96,6 +99,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
Is comment above still correct?
>
> + if (skb->csum_not_inet)
> + hdr->flags &= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
> +
... and a separate flag to tell guest it's ok to set this flag in
outgoing packets.
Also - this chunk looks like a hack fixing up a value we
have set incorrectly.
Specifically this clears all flags except VIRTIO_NET_HDR_F_CSUM_NOT_INET.
Why do this at all? Do we really want to clear e.g. NEEDS_CSUM? I think we do not
since csum_start, csum_offset are set.
Also - what will ever set this flag in the header?
> return 0;
> }
>
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index 5de6ed3..3f279c8 100644
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -36,6 +36,7 @@
> #define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial csum */
> #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Dynamic offload configuration. */
> #define VIRTIO_NET_F_MTU 3 /* Initial MTU advice */
> +#define VIRTIO_NET_F_SCTP_CSUM 4 /* SCTP checksum offload support */
> #define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
> #define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
> #define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
> @@ -101,6 +102,7 @@ struct virtio_net_config {
> struct virtio_net_hdr_v1 {
> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
> #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
> +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET 4 /* Checksum is not inet */
Not very informative. Instead, please specify what is it actually.
> __u8 flags;
> #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
> #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
> --
> 2.9.5
^ permalink raw reply
* Re: [PATCH net-next 1/5] virtio: Add support for SCTP checksum offloading
From: Michael S. Tsirkin @ 2018-04-16 17:09 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Vladislav Yasevich, netdev, linux-sctp, virtualization, jasowang,
nhorman
In-Reply-To: <f5655ab8-f24f-a5a5-d000-2bbb90ecc552@redhat.com>
On Mon, Apr 16, 2018 at 09:45:48AM -0400, Vlad Yasevich wrote:
> On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote:
> > On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote:
> >> To support SCTP checksum offloading, we need to add a new feature
> >> to virtio_net, so we can negotiate support between the hypervisor
> >> and the guest.
> >>
> >> The signalling to the guest that an alternate checksum needs to
> >> be used is done via a new flag in the virtio_net_hdr. If the
> >> flag is set, the host will know to perform an alternate checksum
> >> calculation, which right now is only CRC32c.
> >>
> >> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> >> ---
> >> drivers/net/virtio_net.c | 11 ++++++++---
> >> include/linux/virtio_net.h | 6 ++++++
> >> include/uapi/linux/virtio_net.h | 2 ++
> >> 3 files changed, 16 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> >> index 7b187ec..b601294 100644
> >> --- a/drivers/net/virtio_net.c
> >> +++ b/drivers/net/virtio_net.c
> >> @@ -2724,9 +2724,14 @@ static int virtnet_probe(struct virtio_device *vdev)
> >> /* Do we support "hardware" checksums? */
> >> if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
> >> /* This opens up the world of extra features. */
> >> - dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> >> + netdev_features_t sctp = 0;
> >> +
> >> + if (virtio_has_feature(vdev, VIRTIO_NET_F_SCTP_CSUM))
> >> + sctp |= NETIF_F_SCTP_CRC;
> >> +
> >> + dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
> >> if (csum)
> >> - dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> >> + dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
> >>
> >> if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
> >> dev->hw_features |= NETIF_F_TSO
> >> @@ -2952,7 +2957,7 @@ static struct virtio_device_id id_table[] = {
> >> };
> >>
> >> #define VIRTNET_FEATURES \
> >> - VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
> >> + VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, VIRTIO_NET_F_SCTP_CSUM, \
> >> VIRTIO_NET_F_MAC, \
> >> VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6, \
> >> VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6, \
> >> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> >> index f144216..2e7a64a 100644
> >> --- a/include/linux/virtio_net.h
> >> +++ b/include/linux/virtio_net.h
> >> @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> >>
> >> if (!skb_partial_csum_set(skb, start, off))
> >> return -EINVAL;
> >> +
> >> + if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
> >> + skb->csum_not_inet = 1;
> >> }
> >>
> >> if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> >> @@ -96,6 +99,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> >> hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> >> } /* else everything is zero */
> >>
> >> + if (skb->csum_not_inet)
> >> + hdr->flags &= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
> >> +
> >> return 0;
> >> }
> >>
> >> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> >> index 5de6ed3..3f279c8 100644
> >> --- a/include/uapi/linux/virtio_net.h
> >> +++ b/include/uapi/linux/virtio_net.h
> >> @@ -36,6 +36,7 @@
> >> #define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial csum */
> >> #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Dynamic offload configuration. */
> >> #define VIRTIO_NET_F_MTU 3 /* Initial MTU advice */
> >> +#define VIRTIO_NET_F_SCTP_CSUM 4 /* SCTP checksum offload support */
> >> #define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
> >> #define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
> >> #define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
> >
> > Is this a guest or a host checksum? We should differenciate between the
> > two.
>
> I suppose this is HOST checksum, since it behaves like VIRTIO_NET_F_CSUM only for
> SCTP. I couldn't find the use for the GUEST side flag, since there technically
> isn't any validations and there is no additional mappings from VIRTIO flag to a
> NETIF flag.
>
> If the feature is negotiated, the guest ends up generating partially check-summed
> packets, and the host turns on appropriate flags on it's side. The host will
> also make sure the checksum if fixed up if the guest doesn't support it.
> So 1 flag is currently all that is needed.
>
> -vlad
I see code handling VIRTIO_NET_HDR_F_CSUM_NOT_INET on RX side. Host
needs to know whether it's ok/worth it to set this flag, too.
> >
> >
> >> @@ -101,6 +102,7 @@ struct virtio_net_config {
> >> struct virtio_net_hdr_v1 {
> >> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
> >> #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
> >> +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET 4 /* Checksum is not inet */
> >> __u8 flags;
> >> #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
> >> #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
> >> --
> >> 2.9.5
^ permalink raw reply
* Re: [PATCH net-next 4/5] tun: Add support for SCTP checksum offload
From: Michael S. Tsirkin @ 2018-04-16 17:12 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, virtualization, jasowang, nhorman,
Vladislav Yasevich
In-Reply-To: <20180402134006.10111-5-vyasevic@redhat.com>
On Mon, Apr 02, 2018 at 09:40:05AM -0400, Vladislav Yasevich wrote:
> Adds a new tun offload flag to allow for SCTP checksum offload.
> The flag has to be set by the user and defaults to "no offload".
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
When would user set this flag? Wouldn't that be when
userspace is ready to get SCTP packets without a checksum?
Seems to be this is an indication that when userspace
is qemu running a guest, said guest needs to communicate
the new ability to qemu.
> ---
> drivers/net/tun.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index a1ba262..263bcbe 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -2719,6 +2719,11 @@ static int set_offload(struct tun_struct *tun, unsigned long arg)
> arg &= ~TUN_F_UFO;
> }
>
> + if (arg & TUN_F_SCTP_CSUM) {
> + features |= NETIF_F_SCTP_CRC;
> + arg &= ~TUN_F_SCTP_CSUM;
> + }
> +
> /* This gives the user a way to test for new features in future by
> * trying to set them. */
> if (arg)
> --
> 2.9.5
^ permalink raw reply
* Re: [PATCH net-next 5/5] macvlan/macvtap: Add support for SCTP checksum offload.
From: Michael S. Tsirkin @ 2018-04-16 17:14 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, virtualization, jasowang, nhorman,
Vladislav Yasevich
In-Reply-To: <20180402134006.10111-6-vyasevic@redhat.com>
On Mon, Apr 02, 2018 at 09:40:06AM -0400, Vladislav Yasevich wrote:
> Since we now have support for software CRC32c offload, turn it on
> for macvlan and macvtap devices so that guests can take advantage
> of offload SCTP checksums to the host or host hardware.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> drivers/net/macvlan.c | 5 +++--
> drivers/net/tap.c | 8 +++++---
> include/uapi/linux/if_tun.h | 1 +
> 3 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 725f4b4..646b730 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>
> #define ALWAYS_ON_OFFLOADS \
> (NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
> - NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
> + NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
>
> #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
>
> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
> (NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
> NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
> NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
> - NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
> + NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
> + NETIF_F_SCTP_CRC)
>
> #define MACVLAN_STATE_MASK \
> ((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
> index 9b6cb78..2c8512b 100644
> --- a/drivers/net/tap.c
> +++ b/drivers/net/tap.c
> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
> * check, we either support them all or none.
> */
> if (skb->ip_summed == CHECKSUM_PARTIAL &&
> - !(features & NETIF_F_CSUM_MASK) &&
> - skb_checksum_help(skb))
> + skb_csum_hwoffload_help(skb, features))
> goto drop;
> if (ptr_ring_produce(&q->ring, skb))
> goto drop;
> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
> }
> }
>
> + if (arg & TUN_F_SCTP_CSUM)
> + feature_mask |= NETIF_F_SCTP_CRC;
> +
> /* tun/tap driver inverts the usage for TSO offloads, where
> * setting the TSO bit means that the userspace wants to
> * accept TSO frames and turning it off means that user space
Does not the above comment apply to the new flag too? It seems that
it's value should be inverted for macvtap, and isn't, here.
> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
> case TUNSETOFFLOAD:
> /* let the user check for future flags */
> if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
> - TUN_F_TSO_ECN | TUN_F_UFO))
> + TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
> return -EINVAL;
>
> rtnl_lock();
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index ee432cd..c3bb282 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -86,6 +86,7 @@
> #define TUN_F_TSO6 0x04 /* I can handle TSO for IPv6 packets */
> #define TUN_F_TSO_ECN 0x08 /* I can handle TSO with ECN bits. */
> #define TUN_F_UFO 0x10 /* I can handle UFO packets */
> +#define TUN_F_SCTP_CSUM 0x20 /* I can handle SCTP checksum offload */
>
> /* Protocol info prepended to the packets (when IFF_NO_PI is not set) */
> #define TUN_PKT_STRIP 0x0001
Doesn't this belong in the previous patch?
> 2.9.5
^ permalink raw reply
* [PATCH net-next 0/5] tcp: add zero copy receive
From: Eric Dumazet @ 2018-04-16 17:33 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Neal Cardwell, Yuchung Cheng,
Soheil Hassas Yeganeh, Eric Dumazet
This patch series add mmap() support to TCP sockets for RX zero copy.
While tcp_mmap() patch itself is quite small (~100 LOC), optimal support
for asynchronous mmap() required better SO_RCVLOWAT behavior, and a
test program to demonstrate how mmap() on TCP sockets can be used.
Note that mmap() (and associated munmap()) calls are adding more
pressure on per-process VM semaphore, so might not show benefit
for processus with high number of threads.
Eric Dumazet (5):
tcp: fix SO_RCVLOWAT and RCVBUF autotuning
tcp: fix delayed acks behavior for SO_RCVLOWAT
tcp: avoid extra wakeups for SO_RCVLOWAT users
tcp: implement mmap() for zero copy receive
selftests: net: add tcp_mmap program
include/linux/net.h | 1 +
include/net/tcp.h | 4 +
net/core/sock.c | 5 +-
net/ipv4/af_inet.c | 3 +-
net/ipv4/tcp.c | 138 ++++++++
net/ipv4/tcp_input.c | 22 +-
net/ipv6/af_inet6.c | 3 +-
tools/testing/selftests/net/Makefile | 2 +
tools/testing/selftests/net/tcp_mmap.c | 437 +++++++++++++++++++++++++
9 files changed, 608 insertions(+), 7 deletions(-)
create mode 100644 tools/testing/selftests/net/tcp_mmap.c
--
2.17.0.484.g0c8726318c-goog
^ 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