* [PATCH v4 net 0/3] Restore UFO support to virtio_net devices
From: Vladislav Yasevich @ 2015-02-03 21:36 UTC (permalink / raw)
To: netdev; +Cc: virtualization
commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Thu Oct 30 18:27:12 2014 +0000
drivers/net: Disable UFO through virtio
Turned off UFO support to virtio-net based devices due to issues
with IPv6 fragment id generation for UFO packets. The issue
was that IPv6 UFO/GSO implementation expects the fragment id
to be supplied in skb_shinfo(). However, for packets generated
by the VMs, the fragment id is not supplied which causes all
IPv6 fragments to have the id of 0.
The problem is that turning off UFO support on tap/macvtap
as well as virtio devices caused issues with migrations.
Migrations would fail when moving a vm from a kernel supporting
expecting UFO to work to the newer kernels that disabled UFO.
This series provides a partial solution to address the migration
issue. The series allows us to track whether skb_shinfo()->ip6_frag_id
has been set by treating value of 0 as unset.
This lets GSO code to generate fragment ids if they are necessary
(ex: packet was generated by VM or packet socket).
Since v3:
- Resolved build issue when IPv6 is a module.
- Removed trailing white space.
Since v2:
- Rebase and rebuild to make sure everything works. No changes
to the patches were done.
Since v1:
- Removed the skb bit and use value of 0 as tracker.
- Used Eric's suggestion to set fragment id as 0x80000000 if id
generation procedure yeilded a 0 result.
- Consolidated ipv6 id genration code.
Vladislav Yasevich (3):
ipv6: Select fragment id during UFO segmentation if not set.
Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
packets"
Revert "drivers/net: Disable UFO through virtio"
drivers/net/macvtap.c | 16 ++++++++--------
drivers/net/tun.c | 25 +++++++++----------------
drivers/net/virtio_net.c | 24 ++++++++++--------------
include/net/ipv6.h | 3 +++
net/ipv6/ip6_output.c | 14 --------------
net/ipv6/output_core.c | 41 +++++++++++++++++++++++++++++++++++------
net/ipv6/udp_offload.c | 10 +++++++++-
7 files changed, 74 insertions(+), 59 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH v3 net 1/3] ipv6: Select fragment id during UFO segmentation if not set.
From: Vladislav Yasevich @ 2015-02-03 21:36 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Vladislav Yasevich
In-Reply-To: <1422999377-18777-1-git-send-email-vyasevic@redhat.com>
If the IPv6 fragment id has not been set and we perform
fragmentation due to UFO, select a new fragment id.
We now consider a fragment id of 0 as unset and if id selection
process returns 0 (after all the pertrubations), we set it to
0x80000000, thus giving us ample space not to create collisions
with the next packet we may have to fragment.
When doing UFO integrity checking, we also select the
fragment id if it has not be set yet. This is stored into
the skb_shinfo() thus allowing UFO to function correclty.
This patch also removes duplicate fragment id generation code
and moves ipv6_select_ident() into the header as it may be
used during GSO.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
include/net/ipv6.h | 3 +++
net/ipv6/ip6_output.c | 14 --------------
net/ipv6/output_core.c | 41 +++++++++++++++++++++++++++++++++++------
net/ipv6/udp_offload.c | 10 +++++++++-
4 files changed, 47 insertions(+), 21 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 4292929..9bf85d3 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -671,6 +671,9 @@ static inline int ipv6_addr_diff(const struct in6_addr *a1, const struct in6_add
return __ipv6_addr_diff(a1, a2, sizeof(struct in6_addr));
}
+u32 __ipv6_select_ident(u32 hashrnd, struct in6_addr *dst,
+ struct in6_addr *src);
+void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt);
void ipv6_proxy_select_ident(struct sk_buff *skb);
int ip6_dst_hoplimit(struct dst_entry *dst);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index ce69a12..d28f2a2 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -537,20 +537,6 @@ static void ip6_copy_metadata(struct sk_buff *to, struct sk_buff *from)
skb_copy_secmark(to, from);
}
-static void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
-{
- static u32 ip6_idents_hashrnd __read_mostly;
- u32 hash, id;
-
- net_get_random_once(&ip6_idents_hashrnd, sizeof(ip6_idents_hashrnd));
-
- hash = __ipv6_addr_jhash(&rt->rt6i_dst.addr, ip6_idents_hashrnd);
- hash = __ipv6_addr_jhash(&rt->rt6i_src.addr, hash);
-
- id = ip_idents_reserve(hash, 1);
- fhdr->identification = htonl(id);
-}
-
int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
{
struct sk_buff *frag;
diff --git a/net/ipv6/output_core.c b/net/ipv6/output_core.c
index 97f41a3..54520a0 100644
--- a/net/ipv6/output_core.c
+++ b/net/ipv6/output_core.c
@@ -9,6 +9,24 @@
#include <net/addrconf.h>
#include <net/secure_seq.h>
+u32 __ipv6_select_ident(u32 hashrnd, struct in6_addr *dst, struct in6_addr *src)
+{
+ u32 hash, id;
+
+ hash = __ipv6_addr_jhash(dst, hashrnd);
+ hash = __ipv6_addr_jhash(src, hash);
+
+ /* Treat id of 0 as unset and if we get 0 back from ip_idents_reserve,
+ * set the hight order instead thus minimizing possible future
+ * collisions.
+ */
+ id = ip_idents_reserve(hash, 1);
+ if (unlikely(!id))
+ id = 1 << 31;
+
+ return id;
+}
+
/* This function exists only for tap drivers that must support broken
* clients requesting UFO without specifying an IPv6 fragment ID.
*
@@ -22,7 +40,7 @@ void ipv6_proxy_select_ident(struct sk_buff *skb)
static u32 ip6_proxy_idents_hashrnd __read_mostly;
struct in6_addr buf[2];
struct in6_addr *addrs;
- u32 hash, id;
+ u32 id;
addrs = skb_header_pointer(skb,
skb_network_offset(skb) +
@@ -34,14 +52,25 @@ void ipv6_proxy_select_ident(struct sk_buff *skb)
net_get_random_once(&ip6_proxy_idents_hashrnd,
sizeof(ip6_proxy_idents_hashrnd));
- hash = __ipv6_addr_jhash(&addrs[1], ip6_proxy_idents_hashrnd);
- hash = __ipv6_addr_jhash(&addrs[0], hash);
-
- id = ip_idents_reserve(hash, 1);
- skb_shinfo(skb)->ip6_frag_id = htonl(id);
+ id = __ipv6_select_ident(ip6_proxy_idents_hashrnd,
+ &addrs[1], &addrs[0]);
+ skb_shinfo(skb)->ip6_frag_id = id;
}
EXPORT_SYMBOL_GPL(ipv6_proxy_select_ident);
+void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
+{
+ static u32 ip6_idents_hashrnd __read_mostly;
+ u32 id;
+
+ net_get_random_once(&ip6_idents_hashrnd, sizeof(ip6_idents_hashrnd));
+
+ id = __ipv6_select_ident(ip6_idents_hashrnd, &rt->rt6i_dst.addr,
+ &rt->rt6i_src.addr);
+ fhdr->identification = htonl(id);
+}
+EXPORT_SYMBOL(ipv6_select_ident);
+
int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
{
u16 offset = sizeof(struct ipv6hdr);
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index b6aa8ed..a562769 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -52,6 +52,10 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
+ /* Set the IPv6 fragment id if not set yet */
+ if (!skb_shinfo(skb)->ip6_frag_id)
+ ipv6_proxy_select_ident(skb);
+
segs = NULL;
goto out;
}
@@ -108,7 +112,11 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
fptr->nexthdr = nexthdr;
fptr->reserved = 0;
- fptr->identification = skb_shinfo(skb)->ip6_frag_id;
+ if (skb_shinfo(skb)->ip6_frag_id)
+ fptr->identification = skb_shinfo(skb)->ip6_frag_id;
+ else
+ ipv6_select_ident(fptr,
+ (struct rt6_info *)skb_dst(skb));
/* Fragment the skb. ipv6 header and the remaining fields of the
* fragment header are updated in ipv6_gso_segment()
--
1.9.3
^ permalink raw reply related
* [PATCH v3 net 2/3] Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets"
From: Vladislav Yasevich @ 2015-02-03 21:36 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Vladislav Yasevich
In-Reply-To: <1422999377-18777-1-git-send-email-vyasevic@redhat.com>
This reverts commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7.
Now that GSO layer can track if fragment id has been selected
and can allocate one if necessary, we don't need to do this in
tap and macvtap. This reverts most of the code and only keeps
the new ipv6 fragment id generation function that is still needed.
Fixes: 3d0ad09412ff (drivers/net: Disable UFO through virtio)
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
drivers/net/macvtap.c | 3 ---
drivers/net/tun.c | 6 +-----
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 7df2217..0b86e46 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -17,7 +17,6 @@
#include <linux/fs.h>
#include <linux/uio.h>
-#include <net/ipv6.h>
#include <net/net_namespace.h>
#include <net/rtnetlink.h>
#include <net/sock.h>
@@ -589,8 +588,6 @@ static int macvtap_skb_from_vnet_hdr(struct macvtap_queue *q,
pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
current->comm);
gso_type = SKB_GSO_UDP;
- if (skb->protocol == htons(ETH_P_IPV6))
- ipv6_proxy_select_ident(skb);
break;
default:
return -EINVAL;
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16..5ca42b7 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -65,7 +65,6 @@
#include <linux/nsproxy.h>
#include <linux/virtio_net.h>
#include <linux/rcupdate.h>
-#include <net/ipv6.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
#include <net/rtnetlink.h>
@@ -1167,8 +1166,6 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
break;
}
- skb_reset_network_header(skb);
-
if (gso.gso_type != VIRTIO_NET_HDR_GSO_NONE) {
pr_debug("GSO!\n");
switch (gso.gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
@@ -1189,8 +1186,6 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
current->comm);
}
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
- if (skb->protocol == htons(ETH_P_IPV6))
- ipv6_proxy_select_ident(skb);
break;
}
default:
@@ -1221,6 +1216,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
}
+ skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
rxhash = skb_get_hash(skb);
--
1.9.3
^ permalink raw reply related
* [PATCH v3 net 3/3] Revert "drivers/net: Disable UFO through virtio"
From: Vladislav Yasevich @ 2015-02-03 21:36 UTC (permalink / raw)
To: netdev; +Cc: virtualization, Vladislav Yasevich
In-Reply-To: <1422999377-18777-1-git-send-email-vyasevic@redhat.com>
This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4.
Now that GSO functionality can correctly track if the fragment
id has been selected and select a fragment id if necessary,
we can re-enable UFO on tap/macvap and virtio devices.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
drivers/net/macvtap.c | 13 ++++++++-----
drivers/net/tun.c | 19 ++++++++-----------
drivers/net/virtio_net.c | 24 ++++++++++--------------
3 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 0b86e46..919f4fc 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -80,7 +80,7 @@ static struct cdev macvtap_cdev;
static const struct proto_ops macvtap_socket_ops;
#define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
- NETIF_F_TSO6)
+ NETIF_F_TSO6 | NETIF_F_UFO)
#define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
@@ -585,8 +585,6 @@ static int macvtap_skb_from_vnet_hdr(struct macvtap_queue *q,
gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
- current->comm);
gso_type = SKB_GSO_UDP;
break;
default:
@@ -633,6 +631,8 @@ static void macvtap_skb_to_vnet_hdr(struct macvtap_queue *q,
vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (sinfo->gso_type & SKB_GSO_TCPV6)
vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (sinfo->gso_type & SKB_GSO_UDP)
+ vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
else
BUG();
if (sinfo->gso_type & SKB_GSO_TCP_ECN)
@@ -962,6 +962,9 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
if (arg & TUN_F_TSO6)
feature_mask |= NETIF_F_TSO6;
}
+
+ if (arg & TUN_F_UFO)
+ feature_mask |= NETIF_F_UFO;
}
/* tun/tap driver inverts the usage for TSO offloads, where
@@ -972,7 +975,7 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
* When user space turns off TSO, we turn off GSO/LRO so that
* user-space will not receive TSO frames.
*/
- if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6))
+ if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO))
features |= RX_OFFLOADS;
else
features &= ~RX_OFFLOADS;
@@ -1087,7 +1090,7 @@ static long macvtap_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_TSO_ECN | TUN_F_UFO))
return -EINVAL;
rtnl_lock();
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 5ca42b7..10f9e40 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -186,7 +186,7 @@ struct tun_struct {
struct net_device *dev;
netdev_features_t set_features;
#define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO| \
- NETIF_F_TSO6)
+ NETIF_F_TSO6|NETIF_F_UFO)
int vnet_hdr_sz;
int sndbuf;
@@ -1176,18 +1176,8 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- {
- static bool warned;
-
- if (!warned) {
- warned = true;
- netdev_warn(tun->dev,
- "%s: using disabled UFO feature; please fix this program\n",
- current->comm);
- }
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
break;
- }
default:
tun->dev->stats.rx_frame_errors++;
kfree_skb(skb);
@@ -1294,6 +1284,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (sinfo->gso_type & SKB_GSO_TCPV6)
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (sinfo->gso_type & SKB_GSO_UDP)
+ gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else {
pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
@@ -1742,6 +1734,11 @@ static int set_offload(struct tun_struct *tun, unsigned long arg)
features |= NETIF_F_TSO6;
arg &= ~(TUN_F_TSO4|TUN_F_TSO6);
}
+
+ if (arg & TUN_F_UFO) {
+ features |= NETIF_F_UFO;
+ arg &= ~TUN_F_UFO;
+ }
}
/* This gives the user a way to test for new features in future by
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5ca9771..059fdf1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -490,17 +490,8 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- {
- static bool warned;
-
- if (!warned) {
- warned = true;
- netdev_warn(dev,
- "host using disabled UFO feature; please fix it\n");
- }
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
break;
- }
case VIRTIO_NET_HDR_GSO_TCPV6:
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
break;
@@ -888,6 +879,8 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
+ hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else
BUG();
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCP_ECN)
@@ -1748,7 +1741,7 @@ static int virtnet_probe(struct virtio_device *vdev)
dev->features |= NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST;
if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
- dev->hw_features |= NETIF_F_TSO
+ dev->hw_features |= NETIF_F_TSO | NETIF_F_UFO
| NETIF_F_TSO_ECN | NETIF_F_TSO6;
}
/* Individual feature bits: what can host handle? */
@@ -1758,9 +1751,11 @@ static int virtnet_probe(struct virtio_device *vdev)
dev->hw_features |= NETIF_F_TSO6;
if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_ECN))
dev->hw_features |= NETIF_F_TSO_ECN;
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UFO))
+ dev->hw_features |= NETIF_F_UFO;
if (gso)
- dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
+ dev->features |= dev->hw_features & (NETIF_F_ALL_TSO|NETIF_F_UFO);
/* (!csum && gso) case will be fixed by register_netdev() */
}
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
@@ -1798,7 +1793,8 @@ static int virtnet_probe(struct virtio_device *vdev)
/* If we can receive ANY GSO packets, we must allocate large ones. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6) ||
- virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN))
+ virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN) ||
+ virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UFO))
vi->big_packets = true;
if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
@@ -1994,9 +1990,9 @@ static struct virtio_device_id id_table[] = {
static unsigned int features[] = {
VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM,
VIRTIO_NET_F_GSO, VIRTIO_NET_F_MAC,
- VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_TSO6,
+ 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,
- VIRTIO_NET_F_GUEST_ECN,
+ VIRTIO_NET_F_GUEST_ECN, VIRTIO_NET_F_GUEST_UFO,
VIRTIO_NET_F_MRG_RXBUF, VIRTIO_NET_F_STATUS, VIRTIO_NET_F_CTRL_VQ,
VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net-next 1/2] pkt_sched: fq: avoid artificial bursts for clocked flows
From: Eric Dumazet @ 2015-02-03 22:05 UTC (permalink / raw)
To: Kenneth Klette Jonassen; +Cc: netdev@vger.kernel.org
In-Reply-To: <F3E6220B-F2F4-4985-AECE-9EB9AA7D1C20@ifi.uio.no>
On Tue, 2015-02-03 at 19:51 +0000, Kenneth Klette Jonassen wrote:
> >
> > ACK packets are not paced, ever.
> >
> > This patch also allows skb->ooo_okay being set even if the DATA packet
> > immediately follows a train of ACK packets (as in typical RPC patterns)
> >
> Could you please expand on this?
>
If you followed netdev recently, you might have noticed I am currently
upstreaming patches that we tested more than 6 months at Google.
I am doing this in a non bursty way to ease David Miller work ;)
A hint is given in commit b2532eb9abd88384a
("tcp: fix ooo_okay setting vs Small Queues")
* TODO: Ideally, in-flight pure ACK packets should not matter here.
* One way to get this would be to set skb->truesize = 2 on them.
Thanks
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] pkt_sched: fq: avoid artificial bursts for clocked flows
From: Eric Dumazet @ 2015-02-03 22:06 UTC (permalink / raw)
To: Kenneth Klette Jonassen; +Cc: netdev
In-Reply-To: <1422992932-9893-1-git-send-email-kennetkl@ifi.uio.no>
On Tue, 2015-02-03 at 20:48 +0100, Kenneth Klette Jonassen wrote:
>
> - if (tb[TCA_FQ_INITIAL_QUANTUM])
> - q->initial_quantum = nla_get_u32(tb[TCA_FQ_INITIAL_QUANTUM]);
> + if (tb[TCA_FQ_INITIAL_QUANTUM]) {
> + u32 initial_quantum = nla_get_u32(tb[TCA_FQ_INITIAL_QUANTUM]);
> +
> + if (initial_quantum > q->quantum)
> + q->initial_quantum = initial_quantum - q->quantum;
> + else
> + q->initial_quantum = 0;
> + }
Please do not mix patches. This part already have been Acked by me.
Quite frankly I do not like this patch.
There is no rush, and you touch some critical infrastructure for us.
Always CC me on any fq change, do not assume I catch all netdev
messages.
^ permalink raw reply
* Re: [PATCH v2 17/18] vhost: don't bother copying iovecs in handle_rx(), kill memcpy_toiovecend()
From: Al Viro @ 2015-02-03 22:13 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, netdev, kvm
In-Reply-To: <20150203152154.GA9072@redhat.com>
On Tue, Feb 03, 2015 at 04:21:54PM +0100, Michael S. Tsirkin wrote:
> > Hmm having second thoughts here.
> > Will this modify the iov in vq->iov?
> > If yes, how will recvmsg fill it?
>
> OK that was just me misunderstanding what the
> function does. As it doesn't modify the iovec itself,
> I think there's no issue, my ack stands.
That, BTW, was the point of switching ->sendmsg() and ->recvmsg() to
iov_iter primitives - not only do memcpy_toiovec() et.al. change the
iovec, the way it's done was protocol-dependent, up to and including
the things like "have sent 60 caller-supplied bytes, iovec modified
with only 6 bytes consumed". What's worse, on TCP sendmsg we usually
left iovec unchanged, but sometimes it got drained. Granted, that
happened only after setsockopt() playing caller with TCP_REPAIR (i.e.
checkpoint/restart stuff), but...
^ permalink raw reply
* Re: Per-connection tcp_retries2 and RFC 1122 compliance
From: Willy Tarreau @ 2015-02-03 23:15 UTC (permalink / raw)
To: David Miller; +Cc: John Eckersberg, Neal Cardwell, Yuchung Cheng, Netdev
In-Reply-To: <874mr227bx.fsf@redhat.com>
Hi David,
do you think we could have the fix below queued for -stable ? It
appears to fix some quite annoying issues that are not easy to
debug.
Thanks,
Willy
On Tue, Feb 03, 2015 at 01:11:46PM -0500, John Eckersberg wrote:
> Neal Cardwell <ncardwell@google.com> writes:
> > I believe the functionality you are looking for is the
> > TCP_USER_TIMEOUT socket option:
>
> I had tried that previously, and it did not help my case. The reason
> why is that I was using a downstream kernel (Fedora 21, 3.17.8 in this
> case) and it was missing this commit that went into 3.18:
>
> commit b248230c34970a6c1c17c591d63b464e8d2cfc33
> Author: Yuchung Cheng <ycheng@google.com>
> Date: Mon Sep 29 13:20:38 2014 -0700
>
> tcp: abort orphan sockets stalling on zero window probes
>
> Currently we have two different policies for orphan sockets
> that repeatedly stall on zero window ACKs. If a socket gets
> a zero window ACK when it is transmitting data, the RTO is
> used to probe the window. The socket is aborted after roughly
> tcp_orphan_retries() retries (as in tcp_write_timeout()).
>
> But if the socket was idle when it received the zero window ACK,
> and later wants to send more data, we use the probe timer to
> probe the window. If the receiver always returns zero window ACKs,
> icsk_probes keeps getting reset in tcp_ack() and the orphan socket
> can stall forever until the system reaches the orphan limit (as
> commented in tcp_probe_timer()). This opens up a simple attack
> to create lots of hanging orphan sockets to burn the memory
> and the CPU, as demonstrated in the recent netdev post "TCP
> connection will hang in FIN_WAIT1 after closing if zero window is
> advertised." http://www.spinics.net/lists/netdev/msg296539.html
>
> This patch follows the design in RTO-based probe: we abort an orphan
> socket stalling on zero window when the probe timer reaches both
> the maximum backoff and the maximum RTO. For example, an 100ms RTT
> connection will timeout after roughly 153 seconds (0.3 + 0.6 +
> .... + 76.8) if the receiver keeps the window shut. If the orphan
> socket passes this check, but the system already has too many orphans
> (as in tcp_out_of_resources()), we still abort it but we'll also
> send an RST packet as the connection may still be active.
>
> In addition, we change TCP_USER_TIMEOUT to cover (life or dead)
> sockets stalled on zero-window probes. This changes the semantics
> of TCP_USER_TIMEOUT slightly because it previously only applies
> when the socket has pending transmission.
>
> The key part being that last paragraph about stalled zero-window
> probes. Here's the specific use case where I'm hitting this:
>
> (1) Establish a TCP connection bound to a given IP address
> (2) Remove IP address from host
> (3) Write to socket
>
> This gets kicked back by the IP layer as non-routable, which triggers
> the same behavior as the zero-window probes.
>
> The good news is, I confirmed this is working as expected when I tested
> on 3.19.0-rc7.
>
> Thanks for the pointer, I'll go take my harassment to the relevant
> downstream folks.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 0/3] Slab allocator array operations
From: Jesper Dangaard Brouer @ 2015-02-03 23:19 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrew Morton, linux-kernel, linux-mm, penberg, brouer,
netdev@vger.kernel.org, Joonsoo Kim
In-Reply-To: <alpine.DEB.2.11.1501231827330.10083@gentwo.org>
On Fri, 23 Jan 2015 18:28:00 -0600 (CST)
Christoph Lameter <cl@linux.com> wrote:
> On Fri, 23 Jan 2015, Andrew Morton wrote:
>
> > On Fri, 23 Jan 2015 15:37:27 -0600 Christoph Lameter <cl@linux.com> wrote:
> >
> > > Attached a series of 3 patches to implement functionality to allocate
> > > arrays of pointers to slab objects. This can be used by the slab
> > > allocators to offer more optimized allocation and free paths.
> >
> > What's the driver for this? The networking people, I think? If so,
> > some discussion about that would be useful: who is involved, why they
> > have this need, who are the people we need to bug to get it tested,
> > whether this implementation is found adequate, etc.
Yes, networking people like me ;-)
I promised Christoph that I will performance benchmark this. I'll start
by writing/performing some micro benchmarks, but it first starts to get
really interesting once we plug it into e.g. the networking stack, as
effects as instruction-cache misses due to code size starts to play a
role.
>
> Jesper and I gave a talk at LCA about this. LWN has an article on it.
LWN: Improving Linux networking performance
- http://lwn.net/Articles/629155/
- YouTube: https://www.youtube.com/watch?v=3XG9-X777Jo
LWN: Toward a more efficient slab allocator
- http://lwn.net/Articles/629152/
- YouTube: https://www.youtube.com/watch?v=s0lZzP1jOzI
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] net: sched: One function call less in em_meta_change() after error detection
From: David Miller @ 2015-02-04 0:10 UTC (permalink / raw)
To: elfring; +Cc: jhs, netdev, linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <54CD042E.6030606@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 31 Jan 2015 17:34:54 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 31 Jan 2015 17:18:48 +0100
>
> The meta_delete() function could be called in four cases by the
> em_meta_change() function during error handling even if the passed
> variable "meta" contained still a null pointer.
>
> * This implementation detail could be improved by adjustments for jump labels.
>
> * Let us return immediately after the first failed function call according to
> the current Linux coding style convention.
>
> * Let us delete also unnecessary checks for the variables "err" and
> "meta" there.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
I kind of like the way the code is now, branching to the end of the function
even when cleanups are not necessary.
Inter-function return statements make code harder to audit, for locking
errors, resource leaks, etc.
^ permalink raw reply
* Re: [PATCH v3] net/fsl_pq_mdio: Document supported compatibles
From: David Miller @ 2015-02-04 0:11 UTC (permalink / raw)
To: Emilian.Medve-eDlz3WWmN0ll57MIdRCFDg
Cc: scottwood-eDlz3WWmN0ll57MIdRCFDg,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Kanetkar.Shruti-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1422827911-32629-1-git-send-email-Emilian.Medve-eDlz3WWmN0ll57MIdRCFDg@public.gmane.org>
From: Emil Medve <Emilian.Medve-eDlz3WWmN0ll57MIdRCFDg@public.gmane.org>
Date: Sun, 1 Feb 2015 15:58:31 -0600
> From: Shruti Kanetkar <Kanetkar.Shruti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> The device tree binding(s) document has fallen out of sync with the
> driver code. Update the list of supported devices to reflect current
> driver capabilities
>
> Change-Id: I440d8de2ee2d9c3b7b23e69b3da851cab18a4c9a
> Signed-off-by: Shruti Kanetkar <Kanetkar.Shruti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Emil Medve <Emilian.Medve-eDlz3WWmN0ll57MIdRCFDg@public.gmane.org>
Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] tun: orphan an skb on tx
From: David Miller @ 2015-02-04 0:19 UTC (permalink / raw)
To: dwmw2
Cc: mst, herbert, eric.dumazet, jan.kiszka, netdev, linux-kernel,
qemu-devel
In-Reply-To: <1422862030.11044.86.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Mon, 02 Feb 2015 07:27:10 +0000
> I'm guessing you don't want to push the *whole* management of the TLS
> control connection *and* the UDP transport, and probing the latter with
> keepalives, into the kernel? I certainly don't :)
Whilst Herbert Xu and I have discussed in the past supporting
automatic SSL handling of socket data during socket writes in the
kernel, doing TLS stuff would be a bit of a stretch :-)
^ permalink raw reply
* Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
From: poma @ 2015-02-04 0:20 UTC (permalink / raw)
To: sean darcy
Cc: Community support for Fedora users, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <54BA23CE.70001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 17.01.2015 09:56, poma wrote:
> On 17.01.2015 00:57, sean darcy wrote:
>> On 01/16/2015 07:09 AM, poma wrote:
>>> On 16.01.2015 10:37, Hayes Wang wrote:
>>>> poma [mailto:pomidorabelisima-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>>>>> Sent: Friday, January 16, 2015 4:25 PM
>>>> [...]
>>>>>> This looks like a USB problem. Is there a way to get usb (or
>>>>>> NetworkManager) to reinitialize the driver when this happens?
>>>>>
>>>>> I would ask these people for advice, therefore.
>>>>
>>>> Our hw engineers need to analyse the behavior of the device.
>>>> However, I don't think you have such instrument to provide
>>>> the required information. If we don't know the reason, we
>>>> couldn't give you the proper solution. Besides, your solution
>>>> would work if and only if reloading the driver is helpful.
>>>>
>>>> The issue have to debug from the hardware, and I have no idea
>>>> about what the software could do before analysing the hw. Maybe
>>>> you could try the following driver first to check if it is useful.
>>>>
>>>> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false
>>>>
>>>> Best Regards,
>>>> Hayes
>>>>
>>>
>>> Thanks for your response, Mr. Hayes.
>>>
>>> Mr. Sean, please download and check if "timeout" is still present with built RTL8153 module from REALTEK site, as Mr. Hayes proposed.
>>> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false#2
>>> r8152.53-2.03.0.tar.bz2
>>>
>>> Procedure - should be equal for both, Fedora 21 & 20:
>>>
>>> $ uname -r
>>> 3.17.8-300.fc21.x86_64
>>>
>>> $ su -c 'yum install kernel-devel'
>>>
>>> $ tar xf r8152.53-2.03.0.tar.bz2
>>> $ cd r8152-2.03.0/
>>> $ make
>>> $ su
>>>
>>> # cp 50-usb-realtek-net.rules /etc/udev/rules.d/
>>> # udevadm trigger --action=add
>>>
>>> # modprobe -rv r8152
>>> # cp r8152.ko /lib/modules/$(uname -r)/updates/
>>> # depmod
>>> # modprobe -v r8152
>>>
>>>
>>> poma
>>>
>> OK. Did all that. Now to see if I get the same problem over the next
>> couple of weeks.
>>
>> I'd never heard about the updates subfolder in modules. Very slick.
>>
>> But when I update the kernel, I get to do this again correct? How will I
>
> $ cd r8152-2.03.0/
> $ make clean
> $ make
> $ su
>
> # cp r8152.ko /lib/modules/$(uname -r)/updates/
> # depmod
> # modprobe -v r8152
>
> is part of the procedure necessary for a new i.e. an upgraded kernel.
>
>
>> know that this module has been incorporated in the running kernel.
>> modinfo doesn't give any version info.
>>
>
> $ modinfo r8152 -n
>
> will show the module considered for loading.
>
>
>> BTW, I'm not sure what modprobe --dump-modversions is supposed to do,
>> but it doesn't:
>>
>> #modprobe --dump-modversions r8152
>> modprobe: FATAL: Module r8152 not found.
>> # modprobe --dump-modversions r8152.ko
>> modprobe: FATAL: Module r8152.ko not found.
>> #lsmod | grep 8152
>> r8152 49646 0
>>
>
> "--dump-modversions" will probably show the same error for any module.
>
>
>> Thanks for all your help.
>>
>> sean
>>
>
> YW
>
>
>
Mr. Sean,
is your problem with r8152 resolved, are
"kernel: r8152 2-2:1.0 internal: Tx timeout"
still present?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 01/18] netlink: make the check for "send from tx_ring" deterministic
From: David Miller @ 2015-02-04 0:21 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: viro, netdev
In-Reply-To: <54CF7828.6040605@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Mon, 02 Feb 2015 16:14:16 +0300
> On 2/2/2015 10:59 AM, Al Viro wrote:
>
>> From: Al Viro <viro@zeniv.linux.org.uk>
>
>> + /* It's a really convoluted way for userland to ask for mmaped
>> + * sendmsg(), but that's what we've got... */
>
> Hmm, not sure why DaveM hasn't commented on this broken comment
> formatting (perhaps he was going to fix it while applying?). The
> preferred comment style in the networking code is:
>
> /* bla
> * bla
> */
Indeed, Al can you please audit your whole series for this issue and
respin?
Please also explicitly give me the GIT url to pull from each time you
post the series.
Thanks.
^ permalink raw reply
* [RFC] Possible data stall with RPS and CPU hotplug
From: subashab @ 2015-02-04 0:52 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, therbert
We have an RPS configuration to process packets on Core3 while hardware
interrupts arrive on Core0. We see an occasional stall when Core3 is hot
plugged out and comes back up at a later point in time. At the time of
this stall, we notice that the maximum backlog queue size of 1000 is
reached and subsequent packets are dropped, NAPI is scheduled on Core3,
but softIRQ NET_RX is not raised on Core3.
This leads me to think that possibly the Core3 went offline just before
hitting this conditional cpu_online() check in
net_rps_action_and_irq_enable(), so the IPI was not delivered to Core3.
/* Send pending IPI's to kick RPS processing on remote cpus. */
while (remsd) {
struct softnet_data *next = remsd->rps_ipi_next;
if (cpu_online(remsd->cpu))
__smp_call_function_single(remsd->cpu,
&remsd->csd, 0);
remsd = next;
}
Later when the Core3 comes back online packets start getting enqueued to
Core3 but IPI's are not delivered because NAPI_STATE_SCHED is never
cleared on sofnet_data for Core3.
enqueue_to_backlog()
/* Schedule NAPI for backlog device
* We can use non atomic operation since we own the queue lock
*/
if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {
if (!rps_ipi_queued(sd))
____napi_schedule(sd, &sd->backlog);
}
goto enqueue;
}
Is this analysis correct and does the following patch makes sense?
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 171420e..57663c9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7101,6 +7101,7 @@ static int dev_cpu_callback(struct notifier_block *nfb,
input_queue_head_incr(oldsd);
}
+ clear_bit(NAPI_STATE_SCHED, oldsd->backlog.state);
return NOTIFY_OK;
}
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [RFC] Possible data stall with RPS and CPU hotplug
From: Eric Dumazet @ 2015-02-04 1:19 UTC (permalink / raw)
To: subashab; +Cc: netdev, therbert
In-Reply-To: <90b4251bdb040907ea73f992e1bb96df.squirrel@www.codeaurora.org>
On Wed, 2015-02-04 at 00:52 +0000, subashab@codeaurora.org wrote:
> We have an RPS configuration to process packets on Core3 while hardware
> interrupts arrive on Core0. We see an occasional stall when Core3 is hot
> plugged out and comes back up at a later point in time. At the time of
> this stall, we notice that the maximum backlog queue size of 1000 is
> reached and subsequent packets are dropped, NAPI is scheduled on Core3,
> but softIRQ NET_RX is not raised on Core3.
>
> This leads me to think that possibly the Core3 went offline just before
> hitting this conditional cpu_online() check in
> net_rps_action_and_irq_enable(), so the IPI was not delivered to Core3.
>
> /* Send pending IPI's to kick RPS processing on remote cpus. */
> while (remsd) {
> struct softnet_data *next = remsd->rps_ipi_next;
> if (cpu_online(remsd->cpu))
> __smp_call_function_single(remsd->cpu,
> &remsd->csd, 0);
> remsd = next;
> }
>
> Later when the Core3 comes back online packets start getting enqueued to
> Core3 but IPI's are not delivered because NAPI_STATE_SCHED is never
> cleared on sofnet_data for Core3.
>
> enqueue_to_backlog()
>
> /* Schedule NAPI for backlog device
> * We can use non atomic operation since we own the queue lock
> */
> if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {
> if (!rps_ipi_queued(sd))
> ____napi_schedule(sd, &sd->backlog);
> }
> goto enqueue;
> }
>
> Is this analysis correct and does the following patch makes sense?
>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> ---
> net/core/dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 171420e..57663c9 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7101,6 +7101,7 @@ static int dev_cpu_callback(struct notifier_block *nfb,
> input_queue_head_incr(oldsd);
> }
>
> + clear_bit(NAPI_STATE_SCHED, oldsd->backlog.state);
> return NOTIFY_OK;
> }
>
Really, this should not be needed after commit
ac64da0b83d82abe62f78b3d0e21cca31aea24fa
("net: rps: fix cpu unplug")
If NAPI_STATE_SCHED was set on oldsd->backlog.state, then we must have
found the napi in oldsd->poll_list
So we should have hit line 7125 :
if (napi->poll == process_backlog)
7125: napi->state = 0;
else
____napi_schedule(sd, napi);
So if you find this bit set, there is another bug ?
But it looks like we do not use proper netif_rx() variant in this path.
We run from process context, so we need (at least) following patch :
diff --git a/net/core/dev.c b/net/core/dev.c
index 1d564d68e31a5f361fc233ae90a3a19e82915664..947a291223f5437bc004f7fcbb3a938ecba6ced0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7132,11 +7132,11 @@ static int dev_cpu_callback(struct notifier_block *nfb,
/* Process offline CPU's input_pkt_queue */
while ((skb = __skb_dequeue(&oldsd->process_queue))) {
- netif_rx_internal(skb);
+ netif_rx_ni(skb);
input_queue_head_incr(oldsd);
}
while ((skb = skb_dequeue(&oldsd->input_pkt_queue))) {
- netif_rx_internal(skb);
+ netif_rx_ni(skb);
input_queue_head_incr(oldsd);
}
^ permalink raw reply related
* Re: Question: should local address be expired when updating PMTU?
From: shengyong @ 2015-02-04 1:59 UTC (permalink / raw)
To: Steffen Klassert; +Cc: davem, netdev, yangyingliang, hannes
In-Reply-To: <20150203120140.GU13046@secunet.com>
在 2015/2/3 20:01, Steffen Klassert 写道:
> On Tue, Feb 03, 2015 at 06:54:19PM +0800, shengyong wrote:
>>
>>
>> 在 2015/2/3 17:28, Steffen Klassert 写道:
>>> On Mon, Feb 02, 2015 at 04:20:24PM +0800, shengyong wrote:
>>>
>>> We first need to find out why you receive this Packet Too Big message,
>> The packet is sent by a commercial-off-the-shelf testcase, and I can reproduce the
>> situation by using scapy and creating a packet as the following:
>>
>> $ cat packet-too-big.py
>> #!/usr/bin/python
>>
>> from scapy.all import *
>>
>> # fe80::800:27ff:fe00:0 is linklocal addr of PC
>> # fe80::a00:27ff:fe1a:e2a0 is linklocal addr of VM
>> base=IPv6(src='fe80::800:27ff:fe00:0',dst='fe80::a00:27ff:fe1a:e2a0')
>> pkt_too_big=ICMPv6PacketTooBig(mtu=1024)
>> ext_base=IPv6(src='fe80::a00:27ff:fe1a:e2a0',dst='fe80::a00:27ff:fe1a:e2a0',plen=24)
>> ext_nd_na=ICMPv6ND_NA()
>>
>> packet=base/pkt_too_big/ext_base/ext_nd_na
>> send(packet)
>
> So it is not a valid pmtu update, this make life easier.
>
> Can you please test the patch below (compile tested only)?
Sorry, the later. I test it on 3.10-stable. It can fix this problem. So maybe this is a bug?
And the 3 approaches (different flags are used: RTF_LOCAL, IFF_LOOPBACK and RTF_CACHE) in
these mails can fix the expire of local address. I'm confused about these flags:
* RTF_LOCAL: the entries of local address, like address binded to the native NIC
* RTF_CACHE: all cached entries
* IFF_LOOPBACK: this is a device-related flag, which has the same meaning as RTF_LOCAL
Am I right? If so, I think RTF_LOCAL is appropriate, because we just want entries of local
addresses to be not expired and we don't care other entries (I think if they get expired,
a neigh discovery could find them back).
thx,
Sheng
>
> This should fix your problem, and in combination with the two patches I sent
> out last week, it should cure the whole 'expiring of uncached routes' problem.
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 49596535..4ccfb9c 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1156,7 +1156,8 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
> struct rt6_info *rt6 = (struct rt6_info *)dst;
>
> dst_confirm(dst);
> - if (mtu < dst_mtu(dst) && rt6->rt6i_dst.plen == 128) {
> + if (mtu < dst_mtu(dst) && rt6->rt6i_dst.plen == 128 &&
> + (rt6->rt6i_flags & RTF_CACHE)) {
> struct net *net = dev_net(dst->dev);
>
> rt6->rt6i_flags |= RTF_MODIFIED;
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
^ permalink raw reply
* [PATCH net-next] tcp: do not pace pure ack packets
From: Eric Dumazet @ 2015-02-04 2:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Kenneth Klette Jonassen
From: Eric Dumazet <edumazet@google.com>
When we added pacing to TCP, we decided to let sch_fq take care
of actual pacing.
All TCP had to do was to compute sk->pacing_rate using simple formula:
sk->pacing_rate = 2 * cwnd * mss / rtt
It works well for senders (bulk flows), but not very well for receivers
or even RPC :
cwnd on the receiver can be less than 10, rtt can be around 100ms, so we
can end up pacing ACK packets, slowing down the sender.
Really, only the sender should pace, according to its own logic.
Instead of adding a new bit in skb, or call yet another flow
dissection, we tweak skb->truesize to a small value (2), and
we instruct sch_fq to use new helper and not pace pure ack.
Note this also helps TCP small queue, as ack packets present
in qdisc/NIC do not prevent sending a data packet (RPC workload)
This helps to reduce tx completion overhead, ack packets can use regular
sock_wfree() instead of tcp_wfree() which is a bit more expensive.
This has no impact in the case packets are sent to loopback interface,
as we do not coalesce ack packets (were we would detect skb->truesize
lie)
In case netem (with a delay) is used, skb_orphan_partial() also sets
skb->truesize to 1.
This patch is a combination of two patches we used for about one year at
Google.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/tcp.h | 15 +++++++++++++++
net/ipv4/tcp_output.c | 10 +++++++++-
net/sched/sch_fq.c | 10 ++++++++--
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index b8fdc6bab3f3..637ee490ec81 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1713,4 +1713,19 @@ static inline struct ip_options_rcu *tcp_v4_save_options(struct sk_buff *skb)
return dopt;
}
+/* locally generated TCP pure ACKs have skb->truesize == 2
+ * (check tcp_send_ack() in net/ipv4/tcp_output.c )
+ * This is much faster than dissecting the packet to find out.
+ * (Think of GRE encapsulations, IPv4, IPv6, ...)
+ */
+static inline bool skb_is_tcp_pure_ack(const struct sk_buff *skb)
+{
+ return skb->truesize == 2;
+}
+
+static inline void skb_set_tcp_pure_ack(struct sk_buff *skb)
+{
+ skb->truesize = 2;
+}
+
#endif /* _TCP_H */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 20ab06b228ac..eae35c1ad0aa 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -948,7 +948,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
skb_orphan(skb);
skb->sk = sk;
- skb->destructor = tcp_wfree;
+ skb->destructor = skb_is_tcp_pure_ack(skb) ? sock_wfree : tcp_wfree;
skb_set_hash_from_sk(skb, sk);
atomic_add(skb->truesize, &sk->sk_wmem_alloc);
@@ -3265,6 +3265,14 @@ void tcp_send_ack(struct sock *sk)
skb_reserve(buff, MAX_TCP_HEADER);
tcp_init_nondata_skb(buff, tcp_acceptable_seq(sk), TCPHDR_ACK);
+ /* We do not want pure acks influencing TCP Small Queues or fq/pacing
+ * too much.
+ * SKB_TRUESIZE(max(1 .. 66, MAX_TCP_HEADER)) is unfortunately ~784
+ * We also avoid tcp_wfree() overhead (cache line miss accessing
+ * tp->tsq_flags) by using regular sock_wfree()
+ */
+ skb_set_tcp_pure_ack(buff);
+
/* Send it off, this clears delayed acks for us. */
skb_mstamp_get(&buff->skb_mstamp);
tcp_transmit_skb(sk, buff, 0, sk_gfp_atomic(sk, GFP_ATOMIC));
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 2a50f5c62070..69a3dbf55c60 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -52,6 +52,7 @@
#include <net/pkt_sched.h>
#include <net/sock.h>
#include <net/tcp_states.h>
+#include <net/tcp.h>
/*
* Per flow structure, dynamically allocated
@@ -445,7 +446,9 @@ begin:
goto begin;
}
- if (unlikely(f->head && now < f->time_next_packet)) {
+ skb = f->head;
+ if (unlikely(skb && now < f->time_next_packet &&
+ !skb_is_tcp_pure_ack(skb))) {
head->first = f->next;
fq_flow_set_throttled(q, f);
goto begin;
@@ -464,12 +467,15 @@ begin:
goto begin;
}
prefetch(&skb->end);
- f->time_next_packet = now;
f->credit -= qdisc_pkt_len(skb);
if (f->credit > 0 || !q->rate_enable)
goto out;
+ /* Do not pace locally generated ack packets */
+ if (skb_is_tcp_pure_ack(skb))
+ goto out;
+
rate = q->flow_max_rate;
if (skb->sk)
rate = min(skb->sk->sk_pacing_rate, rate);
^ permalink raw reply related
* Re: [PATCH 0/6 net-next] rhashtable fixes
From: Ying Xue @ 2015-02-04 2:32 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev
In-Reply-To: <20150203172113.GC25410@casper.infradead.org>
On 02/04/2015 01:21 AM, Thomas Graf wrote:
> On 01/30/15 at 05:56pm, Ying Xue wrote:
>> On 01/30/2015 05:29 PM, Thomas Graf wrote:
>>> Right, I see the same soft lockup. Interestingly I cannot trigger it
>>> with the rht test code. I can only trigger it with your Netlink socket
>>> creation stress test. It is definitely related to the deferred worker,
>>> when I disable growing, then the bug disappears.
>>
>> Yes, when I disable expansion, the soft lockup also disappears too.
>
> I have found the last remaining race and can now run your test
> program successfully in an endless loop.
>
> I will resubmit a v2 of this series.
>
>
Thanks! Once I receive your updates, I will test them again.
Regards,
Ying
^ permalink raw reply
* RE: [PATCH v3 3/3] stmmac: pci: add MSI support for Intel Quark X1000
From: Kweh, Hock Leong @ 2015-02-04 3:49 UTC (permalink / raw)
To: Bryan O'Donoghue, Andy Shevchenko
Cc: netdev@vger.kernel.org, davem@davemloft.net, Ahmad, Josef,
Ong, Boon Leong
In-Reply-To: <54CF9CBF.7080806@nexus-software.ie>
> -----Original Message-----
> From: Bryan O'Donoghue [mailto:pure.logic@nexus-software.ie]
> Sent: Monday, February 02, 2015 11:50 PM
> To: Andy Shevchenko
> Cc: netdev@vger.kernel.org; Kweh, Hock Leong; davem@davemloft.net;
> Ahmad, Josef
> Subject: Re: [PATCH v3 3/3] stmmac: pci: add MSI support for Intel Quark
> X1000
>
> On 02/02/15 15:46, Andy Shevchenko wrote:
> > On Mon, 2015-02-02 at 15:17 +0000, Bryan O'Donoghue wrote:
> > > Hi guys.
> > >
> > > Has the issue with PVM masking been addressed ?
> > >
> > > https://lkml.org/lkml/2014/10/1/221
> > >
> > > If not then please drop MSIs from this patchset.
> >
> > I do not see the reason why it should be done on per driver basis.
>
> Agree.
>
> > Care to fix this under arch/x86 then when adding new Quark platform?
>
> Looking into that now.
>
> Hmm - OK -let's aim to get a fix in for the bridge and leave the MSI enable in
> place.
>
I am also agreeing on that. Thanks.
Regards,
Wilson
^ permalink raw reply
* RE: AF_NETDEV - device specific sockets
From: Zayats, Michael @ 2015-02-04 5:51 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev@vger.kernel.org, dborkman
In-Reply-To: <54CFBC14.9080908@gmail.com>
> > More specific example would be when NIC performs certain fast path
> > processing, while punting to the CPU for a slow path.
> > Slow path would be interested to know the punt reason.
> >
> > Another example would be if specific NIC strips S-tag in QinQ case and
> > would like to communicate the stripped Tag to the client.
> >
>
> Right, maybe we need some sort of TLV scheme to pass up the relevant
> info. I'm not sure we want to necessarily bury it in the driver though.
> Perhaps passing auxdata in a TLV format is worth considering.
CMSG formatting in sockets msg_control is pretty close, right?
>
> Just curious do you have NICs that are stripping or inserting more then
> a single tag?
No, just a single tag.
>
> For tagging my current scheme is to strip outer tags using this
> experimental Flow API
>
> http://www.spinics.net/lists/netdev/msg313071.html
>
> and then only report the inner tag to the stack. At the moment I haven't
> found any use cases this is not sufficient.
>
> > There might be many types of custom functionality, agreed between the
> > NIC and the clients, which is not generic or not practical enough for
> inclusion in the kernel.
> >
> > That's why I am looking for a generic, socket like mechanism of
> > device<->client, packet + metadata communication, which wouldn't
> require core kernel modification.
>
> hmm the question is how do the NIC and client "agree" on the format of
> the data and its meaning? If you follow the thread above and also our
> af_packet direct DMA work we are struggling with similar questions,
>
> http://www.spinics.net/lists/netdev/msg311862.html
>
> I think we need some way to "describe" the meta-data or we need to build
> some kernel/uapi standard that defines them.
>
Agreed, some kind of standard way to describe the language is needed.
However, I don't think it should preclude us from having a generic mechanism for communicating custom metadata alongside the packets. When client knows, which NIC type it "talks to".
So far, all the custom drivers that I have seen that needed it, ended up exposing chr device and interposing a custom header between the packets. Same approach that TUN is taking for virtio.
> .John
>
> >
> > Thanks,
> >
> > Michael
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: John Fastabend [mailto:john.fastabend@gmail.com]
> > Sent: Saturday, January 31, 2015 8:41 PM
> > To: Zayats, Michael
> > Cc: netdev@vger.kernel.org
> > Subject: Re: AF_NETDEV - device specific sockets
> >
> > On 01/31/2015 08:20 PM, Zayats, Michael wrote:
> >> Hi,
> >>
> >> I am looking for a generic mechanism that would allow network device
> >> drivers to provide socket interface to user and kernel space clients.
> >>
> >> Such an interface might be used to provide access to important
> >> sub-streams of packets, alongside with device specific packet
> >> metadata, provided through msg_control fields of recv/sendmsg.
> >>
> >> RX Metadata might include device specific information, such as
> >> queuing priorities applied, potential destination interface in case
> >> of switching hardware etc.
> >>
> >> On the transmission, metadata might be used to indicate hardware
> >> specific required optimizations, as well as any other transformation
> >> or accounting required on the packet.
> >>
> >> AF_PACKET based mechanism doesn't allow metadata to be exchanged
> >> between the client and the device driver. Extending it would require
> >> extending of sk_buff and potentially additional per packet
> operations.
> >> Generic Netlink is not intended to pass packets.
> >>
> >> As I am trying to validate generic applicability of such a mechanism,
> >> I see that TUN driver is providing custom socket interface, in order
> >> to deal with user information through msg_control. Only usable inside
> >> the kernel, through custom interface.
> >
> >> Proposed interface
> >> ------------------
> >> Kernel side:
> >> (struct proto *) should be added to struct net_device.
> >> Device driver that is interested to support socket interface would
> populate the pointer.
> >>
> >
> >> User space: After creating AF_NETDEV socket, the only successful
> >> operation would be setting SO_BINDTODEVICE option. Once set, all
> >> socket operations would be implemented by calling functions, that are
> >> registered at struct proto on the appropriate net_device.
> >>
> >> What do you think?
> >> Would you see a better approach?
> >> Some other mechanism that already exists for such a purpose?
> >
> > It might help to come up with specific examples but an alternate
> proposal would be to use skb->priority field and then mqprio to steer
> the traffic to a specific queue and then bind attributes to the queue.
> >
> > For example the NIC offloaded QOS can be mapped on to queues and then
> sockets mapped to the queues.
> >
> > Another example would be to forward all traffic from one queue to a
> virtual fuction in SR-IOV use case. We don't have an interface to do
> this but I have been working on an API that could be used for this.
> >
> > In this case you don't need to modify AF_PACKET interface but
> configure the device correctly. If you need per-packet control you could
> use 'tc' or 'nftables' to do the steering.
> >
> > .John
> >
>
>
> --
> John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add low latency socket busy_poll support
From: Eric Dumazet @ 2015-02-04 5:58 UTC (permalink / raw)
To: Hariprasad Shenai
Cc: netdev, davem, leedom, anish, nirranjan, praveenm, kumaras
In-Reply-To: <1422940816-27402-1-git-send-email-hariprasad@chelsio.com>
On Tue, 2015-02-03 at 10:50 +0530, Hariprasad Shenai wrote:
> @@ -1978,9 +2016,13 @@ static int napi_rx_handler(struct napi_struct *napi, int budget)
> {
> unsigned int params;
> struct sge_rspq *q = container_of(napi, struct sge_rspq, napi);
> - int work_done = process_responses(q, budget);
> + int work_done = 0;
> u32 val;
>
> + if (!cxgb_poll_lock_napi(q))
> + return work_done;
> +
This is very suspicious. Please take a look at commits
24e579c8898aa641 ("bnx2x: fix napi poll return value for repoll")
f104fedc0da126ab ("enic: fix rx napi poll return value")
for context.
^ permalink raw reply
* Re: [PATCH] tun: orphan an skb on tx
From: David Woodhouse @ 2015-02-04 6:35 UTC (permalink / raw)
To: David Miller
Cc: mst, herbert, eric.dumazet, jan.kiszka, netdev, linux-kernel,
qemu-devel
In-Reply-To: <20150203.161955.1916354877509427788.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
On Tue, 2015-02-03 at 16:19 -0800, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Mon, 02 Feb 2015 07:27:10 +0000
>
> > I'm guessing you don't want to push the *whole* management of the TLS
> > control connection *and* the UDP transport, and probing the latter with
> > keepalives, into the kernel? I certainly don't :)
>
> Whilst Herbert Xu and I have discussed in the past supporting
> automatic SSL handling of socket data during socket writes in the
> kernel, doing TLS stuff would be a bit of a stretch :-)
Right. For the DTLS I was thinking we'd do the handshake in userspace
and then hand the UDP socket down. At that point it's basically the same
as ESP with the bytes in a slightly different place.
So I really am looking at an option for "here's a UDP socket to send
those tun packets out on, with <this> encryption setup" as the sanest
plan I can come up with.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/18] netlink: make the check for "send from tx_ring" deterministic
From: Al Viro @ 2015-02-04 6:37 UTC (permalink / raw)
To: David Miller; +Cc: sergei.shtylyov, netdev
In-Reply-To: <20150203.162102.2178616439474613506.davem@davemloft.net>
On Tue, Feb 03, 2015 at 04:21:02PM -0800, David Miller wrote:
> Indeed, Al can you please audit your whole series for this issue and
> respin?
Done, will repost in followups to this one.
> Please also explicitly give me the GIT url to pull from each time you
> post the series.
OK, it's been force-pushed to
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-davem
Shortlog:
Al Viro (18):
netlink: make the check for "send from tx_ring" deterministic
ipv4: raw_send_hdrinc(): pass msghdr
ipv6: rawv6_send_hdrinc(): pass msghdr
vmci: propagate msghdr all way down to __qp_memcpy_to_queue()
rxrpc: switch rxrpc_send_data() to iov_iter primitives
rxrpc: make the users of rxrpc_kernel_send_data() set kvec-backed msg_iter properly
ip: stash a pointer to msghdr in struct ping_fakehdr
ip: convert tcp_sendmsg() to iov_iter primitives
net: switch memcpy_fromiovec()/memcpy_fromiovecend() users to copy_from_iter()
tipc: tipc ->sendmsg() conversion
net: bury net/core/iovec.c - nothing in there is used anymore
crypto: switch af_alg_make_sg() to iov_iter
net/socket.c: fold do_sock_{read,write} into callers
net: switch sockets to ->read_iter/->write_iter
vhost: switch vhost get_indirect() to iov_iter, kill memcpy_fromiovec()
vhost: don't bother with copying iovec in handle_tx()
vhost: don't bother copying iovecs in handle_rx(), kill memcpy_toiovecend()
vhost: vhost_scsi_handle_vq() should just use copy_from_user()
Diffstat:
crypto/af_alg.c | 40 ++----
crypto/algif_hash.c | 45 +++---
crypto/algif_skcipher.c | 74 +++++-----
drivers/misc/vmw_vmci/vmci_queue_pair.c | 16 +--
drivers/vhost/net.c | 91 ++++---------
drivers/vhost/scsi.c | 2 +-
drivers/vhost/vhost.c | 6 +-
fs/afs/rxrpc.c | 14 +-
include/crypto/if_alg.h | 3 +-
include/linux/skbuff.h | 14 +-
include/linux/socket.h | 7 -
include/linux/uio.h | 6 -
include/linux/vmw_vmci_api.h | 2 +-
include/net/ping.h | 2 +-
include/net/sock.h | 18 ++-
include/net/udplite.h | 3 +-
lib/Makefile | 2 +-
lib/iovec.c | 87 ------------
net/core/Makefile | 2 +-
net/core/iovec.c | 137 -------------------
net/ipv4/ip_output.c | 6 +-
net/ipv4/ping.c | 17 ++-
net/ipv4/raw.c | 7 +-
net/ipv4/tcp.c | 233 +++++++++++++++-----------------
net/ipv4/tcp_output.c | 11 +-
net/ipv6/ping.c | 3 +-
net/ipv6/raw.c | 7 +-
net/netlink/af_netlink.c | 5 +
net/rxrpc/ar-output.c | 46 ++-----
net/socket.c | 76 ++++-------
net/tipc/msg.c | 7 +-
net/tipc/socket.c | 14 +-
net/vmw_vsock/vmci_transport.c | 3 +-
33 files changed, 320 insertions(+), 686 deletions(-)
delete mode 100644 lib/iovec.c
delete mode 100644 net/core/iovec.c
^ permalink raw reply
* [PATCH v3 15/18] vhost: switch vhost get_indirect() to iov_iter, kill memcpy_fromiovec()
From: Al Viro @ 2015-02-04 6:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, virtualization, kvm, Michael S. Tsirkin
In-Reply-To: <20150204063730.GG29656@ZenIV.linux.org.uk>
From: Al Viro <viro@zeniv.linux.org.uk>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: kvm@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
drivers/vhost/vhost.c | 6 ++++--
include/linux/uio.h | 1 -
lib/iovec.c | 25 -------------------------
3 files changed, 4 insertions(+), 28 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index cb807d0..2ee2826 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1125,6 +1125,7 @@ static int get_indirect(struct vhost_virtqueue *vq,
struct vring_desc desc;
unsigned int i = 0, count, found = 0;
u32 len = vhost32_to_cpu(vq, indirect->len);
+ struct iov_iter from;
int ret;
/* Sanity check */
@@ -1142,6 +1143,7 @@ static int get_indirect(struct vhost_virtqueue *vq,
vq_err(vq, "Translation failure %d in indirect.\n", ret);
return ret;
}
+ iov_iter_init(&from, READ, vq->indirect, ret, len);
/* We will use the result as an address to read from, so most
* architectures only need a compiler barrier here. */
@@ -1164,8 +1166,8 @@ static int get_indirect(struct vhost_virtqueue *vq,
i, count);
return -EINVAL;
}
- if (unlikely(memcpy_fromiovec((unsigned char *)&desc,
- vq->indirect, sizeof desc))) {
+ if (unlikely(copy_from_iter(&desc, sizeof(desc), &from) !=
+ sizeof(desc))) {
vq_err(vq, "Failed indirect descriptor: idx %d, %zx\n",
i, (size_t)vhost64_to_cpu(vq, indirect->addr) + i * sizeof desc);
return -EINVAL;
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 1c5e453..af3439f 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -135,7 +135,6 @@ static inline void iov_iter_reexpand(struct iov_iter *i, size_t count)
size_t csum_and_copy_to_iter(void *addr, size_t bytes, __wsum *csum, struct iov_iter *i);
size_t csum_and_copy_from_iter(void *addr, size_t bytes, __wsum *csum, struct iov_iter *i);
-int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
int offset, int len);
int memcpy_toiovecend(const struct iovec *v, unsigned char *kdata,
diff --git a/lib/iovec.c b/lib/iovec.c
index 2d99cb4..4a90875 100644
--- a/lib/iovec.c
+++ b/lib/iovec.c
@@ -3,31 +3,6 @@
#include <linux/uio.h>
/*
- * Copy iovec to kernel. Returns -EFAULT on error.
- *
- * Note: this modifies the original iovec.
- */
-
-int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len)
-{
- while (len > 0) {
- if (iov->iov_len) {
- int copy = min_t(unsigned int, len, iov->iov_len);
- if (copy_from_user(kdata, iov->iov_base, copy))
- return -EFAULT;
- len -= copy;
- kdata += copy;
- iov->iov_base += copy;
- iov->iov_len -= copy;
- }
- iov++;
- }
-
- return 0;
-}
-EXPORT_SYMBOL(memcpy_fromiovec);
-
-/*
* Copy kernel to iovec. Returns -EFAULT on error.
*/
--
2.1.4
^ permalink raw reply related
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