tun: export underlying socket

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and exports access to this socket to modules.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

First user of this interface will be vhost virtualization accelerator.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

This patch is on top of net-next master.
An alternative approach would be to add an ioctl to tun, to export the underlying socket to userspace: a uniform way to work with a network device and the host stack might be useful there, as well. Kernel users could then do sockfd_lookup to get the socket. I decided against it for now as it requires more code. Please comment.

 drivers/net/tun.c      |   78 +++++++++++++++++++++++++++++++++++++++++++----
 include/linux/if_tun.h |   14 ++++++++
 2 files changed, 85 insertions(+), 7 deletions(-)

drivers/net/tun.c +2 -0

index 589a44a..76f5faa 100644
@@ -151,6 +151,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
 	err = 0;
 	tfile->tun = tun;
 	tun->tfile = tfile;
+	tun->socket.file = file;
 	dev_hold(tun->dev);
 	sock_hold(tun->socket.sk);
 	atomic_inc(&tfile->count);

@@ -165,6 +166,7 @@ static void __tun_detach(struct tun_struct *tun)
 	/* Detach from net device */
 	netif_tx_lock_bh(tun->dev);
 	tun->tfile = NULL;
+	tun->socket.file = NULL;
 	netif_tx_unlock_bh(tun->dev);
 
 	/* Drop read queue */

drivers/net/tun.c +68 -6

 	tun->dev->stats.tx_packets++;
 	tun->dev->stats.tx_bytes += len;

@@ -758,12 +760,10 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
 	return total;
 }
 
-static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
-			    unsigned long count, loff_t pos)
+static ssize_t tun_do_read(struct tun_struct *tun,
+			   struct kiocb *iocb, const struct iovec *iv,
+			   unsigned long count, int noblock)
 {
-	struct file *file = iocb->ki_filp;
-	struct tun_file *tfile = file->private_data;
-	struct tun_struct *tun = __tun_get(tfile);
 	DECLARE_WAITQUEUE(wait, current);
 	struct sk_buff *skb;
 	ssize_t len, ret = 0;

@@ -785,7 +785,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
 
 		/* Read frames from the queue */
 		if (!(skb=skb_dequeue(&tun->socket.sk->sk_receive_queue))) {
-			if (file->f_flags & O_NONBLOCK) {
+			if (noblock) {
 				ret = -EAGAIN;
 				break;
 			}

@@ -813,6 +813,21 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
 	remove_wait_queue(&tun->socket.wait, &wait);
 
 out:
+	return ret;
+}
+
+static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
+			    unsigned long count, loff_t pos)
+{
+	struct file *file = iocb->ki_filp;
+	struct tun_file *tfile = file->private_data;
+	struct tun_struct *tun = __tun_get(tfile);
+	ssize_t ret;
+
+	if (!tun)
+		return -EBADFD;
+	ret = tun_do_read(tun, iocb, iv, count, file->f_flags & O_NONBLOCK);
+	ret = min_t(ssize_t, ret, count);
 	tun_put(tun);
 	return ret;
 }

@@ -865,6 +880,37 @@ static void tun_sock_destruct(struct sock *sk)
 	free_netdev(container_of(sk, struct tun_sock, sk)->tun->dev);
 }
 
+static int tun_sendmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	return tun_get_user(tun, m->msg_iov, total_len,
+			    m->msg_flags & MSG_DONTWAIT);
+}
+
+static int tun_recvmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len,
+		       int flags)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	int ret;
+	if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+		return -EINVAL;
+	ret = tun_do_read(tun, iocb, m->msg_iov, total_len,
+			  flags & MSG_DONTWAIT);
+	if (ret > total_len) {
+		m->msg_flags |= MSG_TRUNC;
+		ret = flags & MSG_TRUNC ? ret : total_len;
+	}
+	return ret;
+}
+
+/* Ops structure to mimic raw sockets with tun */
+static const struct proto_ops tun_socket_ops = {
+	.sendmsg = tun_sendmsg,
+	.recvmsg = tun_recvmsg,
+};
+
 static struct proto tun_proto = {
 	.name		= "tun",
 	.owner		= THIS_MODULE,

@@ -982,6 +1028,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
 			goto err_free_dev;
 
 		init_waitqueue_head(&tun->socket.wait);
+		tun->socket.ops = &tun_socket_ops;
 		sock_init_data(&tun->socket, sk);
 		sk->sk_write_space = tun_sock_write_space;
 		sk->sk_sndbuf = INT_MAX;

@@ -1483,6 +1530,23 @@ static void tun_cleanup(void)
 	rtnl_link_unregister(&tun_link_ops);
 }
 
+/* Get an underlying socket object from tun file.  Returns error unless file is
+ * attached to a device.  The returned object works like a packet socket, it
+ * can be used for sock_sendmsg/sock_recvmsg.  The caller is responsible for
+ * holding a reference to the file for as long as the socket is in use. */
+struct socket *tun_get_socket(struct file *file)
+{
+	struct tun_struct *tun;
+	if (file->f_op != &tun_fops)
+		return ERR_PTR(-EINVAL);
+	tun = tun_get(file);
+	if (!tun)
+		return ERR_PTR(-EBADFD);
+	tun_put(tun);
+	return &tun->socket;
+}
+EXPORT_SYMBOL_GPL(tun_get_socket);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);

include/linux/if_tun.h +14 -0

index 3f5fd52..404abe0 100644
@@ -86,4 +86,18 @@ struct tun_filter {
 	__u8   addr[0][ETH_ALEN];
 };
 
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
+struct socket *tun_get_socket(struct file *);
+#else
+#include <linux/err.h>
+#include <linux/errno.h>
+struct file;
+struct socket;
+static inline struct socket *tun_get_socket(struct file *f)
+{
+	return ERR_PTR(-EINVAL);
+}
+#endif /* CONFIG_TUN */
+#endif /* __KERNEL__ */
 #endif /* __IF_TUN_H */

Quoted 52 lines · Michael S. Tsirkin

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and exports access to this socket to modules.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

First user of this interface will be vhost virtualization accelerator.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

This patch is on top of net-next master.
An alternative approach would be to add an ioctl to tun, to export the underlying socket to userspace: a uniform way to work with a network device and the host stack might be useful there, as well. Kernel users could then do sockfd_lookup to get the socket. I decided against it for now as it requires more code. Please comment.

 drivers/net/tun.c      |   78 +++++++++++++++++++++++++++++++++++++++++++----
 include/linux/if_tun.h |   14 ++++++++
 2 files changed, 85 insertions(+), 7 deletions(-)

drivers/net/tun.c +2 -0

index 589a44a..76f5faa 100644
@@ -151,6 +151,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
 	err = 0;
 	tfile->tun = tun;
 	tun->tfile = tfile;
+	tun->socket.file = file;
 	dev_hold(tun->dev);
 	sock_hold(tun->socket.sk);
 	atomic_inc(&tfile->count);

@@ -165,6 +166,7 @@ static void __tun_detach(struct tun_struct *tun)
 	/* Detach from net device */
 	netif_tx_lock_bh(tun->dev);
 	tun->tfile = NULL;
+	tun->socket.file = NULL;
 	netif_tx_unlock_bh(tun->dev);
 
 	/* Drop read queue */

@@ -750,7 +752,7 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
 	len = min_t(int, skb->len, len);
 

drivers/net/tun.c static __inline__ ssize_t tun_put_user(struct tun_struct *tun, · line 755

Quoted 3 lines

drivers/net/tun.c +1 -1

 	skb_copy_datagram_const_iovec(skb, 0, iv, total, len);
-	total += len;
+	total += skb->len;

Why are you changing this ?

This is very strange that read() can return
a bigger length than what was asked by user...

Quoted 143 lines

drivers/net/tun.c +68 -6

 	tun->dev->stats.tx_packets++;
 	tun->dev->stats.tx_bytes += len;

@@ -758,12 +760,10 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
 	return total;
 }
 
-static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
-			    unsigned long count, loff_t pos)
+static ssize_t tun_do_read(struct tun_struct *tun,
+			   struct kiocb *iocb, const struct iovec *iv,
+			   unsigned long count, int noblock)
 {
-	struct file *file = iocb->ki_filp;
-	struct tun_file *tfile = file->private_data;
-	struct tun_struct *tun = __tun_get(tfile);
 	DECLARE_WAITQUEUE(wait, current);
 	struct sk_buff *skb;
 	ssize_t len, ret = 0;

@@ -785,7 +785,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
 
 		/* Read frames from the queue */
 		if (!(skb=skb_dequeue(&tun->socket.sk->sk_receive_queue))) {
-			if (file->f_flags & O_NONBLOCK) {
+			if (noblock) {
 				ret = -EAGAIN;
 				break;
 			}

@@ -813,6 +813,21 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
 	remove_wait_queue(&tun->socket.wait, &wait);
 
 out:
+	return ret;
+}
+
+static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
+			    unsigned long count, loff_t pos)
+{
+	struct file *file = iocb->ki_filp;
+	struct tun_file *tfile = file->private_data;
+	struct tun_struct *tun = __tun_get(tfile);
+	ssize_t ret;
+
+	if (!tun)
+		return -EBADFD;
+	ret = tun_do_read(tun, iocb, iv, count, file->f_flags & O_NONBLOCK);
+	ret = min_t(ssize_t, ret, count);
 	tun_put(tun);
 	return ret;
 }

@@ -865,6 +880,37 @@ static void tun_sock_destruct(struct sock *sk)
 	free_netdev(container_of(sk, struct tun_sock, sk)->tun->dev);
 }
 
+static int tun_sendmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	return tun_get_user(tun, m->msg_iov, total_len,
+			    m->msg_flags & MSG_DONTWAIT);
+}
+
+static int tun_recvmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len,
+		       int flags)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	int ret;
+	if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+		return -EINVAL;
+	ret = tun_do_read(tun, iocb, m->msg_iov, total_len,
+			  flags & MSG_DONTWAIT);
+	if (ret > total_len) {
+		m->msg_flags |= MSG_TRUNC;
+		ret = flags & MSG_TRUNC ? ret : total_len;
+	}
+	return ret;
+}
+
+/* Ops structure to mimic raw sockets with tun */
+static const struct proto_ops tun_socket_ops = {
+	.sendmsg = tun_sendmsg,
+	.recvmsg = tun_recvmsg,
+};
+
 static struct proto tun_proto = {
 	.name		= "tun",
 	.owner		= THIS_MODULE,

@@ -982,6 +1028,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
 			goto err_free_dev;
 
 		init_waitqueue_head(&tun->socket.wait);
+		tun->socket.ops = &tun_socket_ops;
 		sock_init_data(&tun->socket, sk);
 		sk->sk_write_space = tun_sock_write_space;
 		sk->sk_sndbuf = INT_MAX;

@@ -1483,6 +1530,23 @@ static void tun_cleanup(void)
 	rtnl_link_unregister(&tun_link_ops);
 }
 
+/* Get an underlying socket object from tun file.  Returns error unless file is
+ * attached to a device.  The returned object works like a packet socket, it
+ * can be used for sock_sendmsg/sock_recvmsg.  The caller is responsible for
+ * holding a reference to the file for as long as the socket is in use. */
+struct socket *tun_get_socket(struct file *file)
+{
+	struct tun_struct *tun;
+	if (file->f_op != &tun_fops)
+		return ERR_PTR(-EINVAL);
+	tun = tun_get(file);
+	if (!tun)
+		return ERR_PTR(-EBADFD);
+	tun_put(tun);
+	return &tun->socket;
+}
+EXPORT_SYMBOL_GPL(tun_get_socket);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);

include/linux/if_tun.h +14 -0

index 3f5fd52..404abe0 100644
@@ -86,4 +86,18 @@ struct tun_filter {
 	__u8   addr[0][ETH_ALEN];
 };
 
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
+struct socket *tun_get_socket(struct file *);
+#else
+#include <linux/err.h>
+#include <linux/errno.h>
+struct file;
+struct socket;
+static inline struct socket *tun_get_socket(struct file *f)
+{
+	return ERR_PTR(-EINVAL);
+}
+#endif /* CONFIG_TUN */
+#endif /* __KERNEL__ */
 #endif /* __IF_TUN_H */

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and exports access to this socket to modules.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

First user of this interface will be vhost virtualization accelerator.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

This patch is on top of net-next master.
An alternative approach would be to add an ioctl to tun, to export the underlying socket to userspace: a uniform way to work with a network device and the host stack might be useful there, as well. Kernel users could then do sockfd_lookup to get the socket. I decided against it for now as it requires more code. Please comment.

 drivers/net/tun.c      |   78
 +++++++++++++++++++++++++++++++++++++++++++---- include/linux/if_tun.h |  
 14 ++++++++
 2 files changed, 85 insertions(+), 7 deletions(-)

drivers/net/tun.c +7 -6

index 589a44a..76f5faa 100644
@@ -151,6 +151,7 @@ static int tun_attach(struct tun_struct *tun, struct
 file *file) err = 0;
 	tfile->tun = tun;
 	tun->tfile = tfile;
+	tun->socket.file = file;
 	dev_hold(tun->dev);
 	sock_hold(tun->socket.sk);
 	atomic_inc(&tfile->count);

@@ -165,6 +166,7 @@ static void __tun_detach(struct tun_struct *tun)
 	/* Detach from net device */
 	netif_tx_lock_bh(tun->dev);
 	tun->tfile = NULL;
+	tun->socket.file = NULL;
 	netif_tx_unlock_bh(tun->dev);
 
 	/* Drop read queue */

@@ -750,7 +752,7 @@ static __inline__ ssize_t tun_put_user(struct
 tun_struct *tun, len = min_t(int, skb->len, len);
 
 	skb_copy_datagram_const_iovec(skb, 0, iv, total, len);
-	total += len;
+	total += skb->len;
 
 	tun->dev->stats.tx_packets++;
 	tun->dev->stats.tx_bytes += len;

@@ -758,12 +760,10 @@ static __inline__ ssize_t tun_put_user(struct
 tun_struct *tun, return total;
 }
 
-static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec
 *iv, -			    unsigned long count, loff_t pos)
+static ssize_t tun_do_read(struct tun_struct *tun,
+			   struct kiocb *iocb, const struct iovec *iv,
+			   unsigned long count, int noblock)
 {
-	struct file *file = iocb->ki_filp;
-	struct tun_file *tfile = file->private_data;
-	struct tun_struct *tun = __tun_get(tfile);
 	DECLARE_WAITQUEUE(wait, current);
 	struct sk_buff *skb;
 	ssize_t len, ret = 0;

@@ -785,7 +785,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb,
 const struct iovec *iv,
 
 		/* Read frames from the queue */
 		if (!(skb=skb_dequeue(&tun->socket.sk->sk_receive_queue))) {
-			if (file->f_flags & O_NONBLOCK) {
+			if (noblock) {
 				ret = -EAGAIN;
 				break;

drivers/net/tun.c +59 -0

 			}

@@ -813,6 +813,21 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb,
 const struct iovec *iv, remove_wait_queue(&tun->socket.wait, &wait);
 
 out:
+	return ret;
+}
+
+static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec
 *iv, +			    unsigned long count, loff_t pos)
+{
+	struct file *file = iocb->ki_filp;
+	struct tun_file *tfile = file->private_data;
+	struct tun_struct *tun = __tun_get(tfile);
+	ssize_t ret;
+
+	if (!tun)
+		return -EBADFD;
+	ret = tun_do_read(tun, iocb, iv, count, file->f_flags & O_NONBLOCK);
+	ret = min_t(ssize_t, ret, count);
 	tun_put(tun);
 	return ret;
 }

@@ -865,6 +880,37 @@ static void tun_sock_destruct(struct sock *sk)
 	free_netdev(container_of(sk, struct tun_sock, sk)->tun->dev);
 }
 
+static int tun_sendmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	return tun_get_user(tun, m->msg_iov, total_len,
+			    m->msg_flags & MSG_DONTWAIT);
+}
+
+static int tun_recvmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len,
+		       int flags)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	int ret;
+	if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+		return -EINVAL;
+	ret = tun_do_read(tun, iocb, m->msg_iov, total_len,
+			  flags & MSG_DONTWAIT);
+	if (ret > total_len) {
+		m->msg_flags |= MSG_TRUNC;
+		ret = flags & MSG_TRUNC ? ret : total_len;
+	}
+	return ret;
+}
+
+/* Ops structure to mimic raw sockets with tun */
+static const struct proto_ops tun_socket_ops = {
+	.sendmsg = tun_sendmsg,
+	.recvmsg = tun_recvmsg,
+};
+
 static struct proto tun_proto = {
 	.name		= "tun",
 	.owner		= THIS_MODULE,

@@ -982,6 +1028,7 @@ static int tun_set_iff(struct net *net, struct file
 *file, struct ifreq *ifr) goto err_free_dev;
 
 		init_waitqueue_head(&tun->socket.wait);
+		tun->socket.ops = &tun_socket_ops;
 		sock_init_data(&tun->socket, sk);
 		sk->sk_write_space = tun_sock_write_space;
 		sk->sk_sndbuf = INT_MAX;

@@ -1483,6 +1530,23 @@ static void tun_cleanup(void)
 	rtnl_link_unregister(&tun_link_ops);
 }
 
+/* Get an underlying socket object from tun file.  Returns error unless
 file is + * attached to a device.  The returned object works like a packet
 socket, it + * can be used for sock_sendmsg/sock_recvmsg.  The caller is
 responsible for + * holding a reference to the file for as long as the
 socket is in use. */ +struct socket *tun_get_socket(struct file *file)
+{
+	struct tun_struct *tun;
+	if (file->f_op != &tun_fops)
+		return ERR_PTR(-EINVAL);
+	tun = tun_get(file);
+	if (!tun)
+		return ERR_PTR(-EBADFD);
+	tun_put(tun);
+	return &tun->socket;
+}
+EXPORT_SYMBOL_GPL(tun_get_socket);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);

include/linux/if_tun.h +14 -0

index 3f5fd52..404abe0 100644
@@ -86,4 +86,18 @@ struct tun_filter {
 	__u8   addr[0][ETH_ALEN];
 };
 
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
+struct socket *tun_get_socket(struct file *);
+#else
+#include <linux/err.h>
+#include <linux/errno.h>
+struct file;
+struct socket;
+static inline struct socket *tun_get_socket(struct file *f)
+{
+	return ERR_PTR(-EINVAL);
+}
+#endif /* CONFIG_TUN */
+#endif /* __KERNEL__ */
 #endif /* __IF_TUN_H */

Quoted 11 lines · Michael S. Tsirkin

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and exports access to this socket to modules.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

Quoted 2 lines

First user of this interface will be vhost virtualization accelerator.

No comments on the code at this point - I'm just trying to understand the intended user right now which I'm assuming is the vhost-net bits you sent previously?

Quoted 187 lines

Signed-off-by Michael S. Tsirkin <[email protected]>

---

This patch is on top of net-next master.
An alternative approach would be to add an ioctl to tun, to export the underlying socket to userspace: a uniform way to work with a network device and the host stack might be useful there, as well. Kernel users could then do sockfd_lookup to get the socket. I decided against it for now as it requires more code. Please comment.

 drivers/net/tun.c      |   78
 +++++++++++++++++++++++++++++++++++++++++++---- include/linux/if_tun.h |  
 14 ++++++++
 2 files changed, 85 insertions(+), 7 deletions(-)

drivers/net/tun.c +7 -6

index 589a44a..76f5faa 100644
@@ -151,6 +151,7 @@ static int tun_attach(struct tun_struct *tun, struct
 file *file) err = 0;
 	tfile->tun = tun;
 	tun->tfile = tfile;
+	tun->socket.file = file;
 	dev_hold(tun->dev);
 	sock_hold(tun->socket.sk);
 	atomic_inc(&tfile->count);

@@ -165,6 +166,7 @@ static void __tun_detach(struct tun_struct *tun)
 	/* Detach from net device */
 	netif_tx_lock_bh(tun->dev);
 	tun->tfile = NULL;
+	tun->socket.file = NULL;
 	netif_tx_unlock_bh(tun->dev);
 
 	/* Drop read queue */

@@ -750,7 +752,7 @@ static __inline__ ssize_t tun_put_user(struct
 tun_struct *tun, len = min_t(int, skb->len, len);
 
 	skb_copy_datagram_const_iovec(skb, 0, iv, total, len);
-	total += len;
+	total += skb->len;
 
 	tun->dev->stats.tx_packets++;
 	tun->dev->stats.tx_bytes += len;

@@ -758,12 +760,10 @@ static __inline__ ssize_t tun_put_user(struct
 tun_struct *tun, return total;
 }
 
-static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec
 *iv, -			    unsigned long count, loff_t pos)
+static ssize_t tun_do_read(struct tun_struct *tun,
+			   struct kiocb *iocb, const struct iovec *iv,
+			   unsigned long count, int noblock)
 {
-	struct file *file = iocb->ki_filp;
-	struct tun_file *tfile = file->private_data;
-	struct tun_struct *tun = __tun_get(tfile);
 	DECLARE_WAITQUEUE(wait, current);
 	struct sk_buff *skb;
 	ssize_t len, ret = 0;

@@ -785,7 +785,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb,
 const struct iovec *iv,
 
 		/* Read frames from the queue */
 		if (!(skb=skb_dequeue(&tun->socket.sk->sk_receive_queue))) {
-			if (file->f_flags & O_NONBLOCK) {
+			if (noblock) {
 				ret = -EAGAIN;
 				break;

drivers/net/tun.c +59 -0

 			}

@@ -813,6 +813,21 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb,
 const struct iovec *iv, remove_wait_queue(&tun->socket.wait, &wait);
 
 out:
+	return ret;
+}
+
+static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec
 *iv, +			    unsigned long count, loff_t pos)
+{
+	struct file *file = iocb->ki_filp;
+	struct tun_file *tfile = file->private_data;
+	struct tun_struct *tun = __tun_get(tfile);
+	ssize_t ret;
+
+	if (!tun)
+		return -EBADFD;
+	ret = tun_do_read(tun, iocb, iv, count, file->f_flags & O_NONBLOCK);
+	ret = min_t(ssize_t, ret, count);
 	tun_put(tun);
 	return ret;
 }

@@ -865,6 +880,37 @@ static void tun_sock_destruct(struct sock *sk)
 	free_netdev(container_of(sk, struct tun_sock, sk)->tun->dev);
 }
 
+static int tun_sendmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	return tun_get_user(tun, m->msg_iov, total_len,
+			    m->msg_flags & MSG_DONTWAIT);
+}
+
+static int tun_recvmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *m, size_t total_len,
+		       int flags)
+{
+	struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+	int ret;
+	if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+		return -EINVAL;
+	ret = tun_do_read(tun, iocb, m->msg_iov, total_len,
+			  flags & MSG_DONTWAIT);
+	if (ret > total_len) {
+		m->msg_flags |= MSG_TRUNC;
+		ret = flags & MSG_TRUNC ? ret : total_len;
+	}
+	return ret;
+}
+
+/* Ops structure to mimic raw sockets with tun */
+static const struct proto_ops tun_socket_ops = {
+	.sendmsg = tun_sendmsg,
+	.recvmsg = tun_recvmsg,
+};
+
 static struct proto tun_proto = {
 	.name		= "tun",
 	.owner		= THIS_MODULE,

@@ -982,6 +1028,7 @@ static int tun_set_iff(struct net *net, struct file
 *file, struct ifreq *ifr) goto err_free_dev;
 
 		init_waitqueue_head(&tun->socket.wait);
+		tun->socket.ops = &tun_socket_ops;
 		sock_init_data(&tun->socket, sk);
 		sk->sk_write_space = tun_sock_write_space;
 		sk->sk_sndbuf = INT_MAX;

@@ -1483,6 +1530,23 @@ static void tun_cleanup(void)
 	rtnl_link_unregister(&tun_link_ops);
 }
 
+/* Get an underlying socket object from tun file.  Returns error unless
 file is + * attached to a device.  The returned object works like a packet
 socket, it + * can be used for sock_sendmsg/sock_recvmsg.  The caller is
 responsible for + * holding a reference to the file for as long as the
 socket is in use. */ +struct socket *tun_get_socket(struct file *file)
+{
+	struct tun_struct *tun;
+	if (file->f_op != &tun_fops)
+		return ERR_PTR(-EINVAL);
+	tun = tun_get(file);
+	if (!tun)
+		return ERR_PTR(-EBADFD);
+	tun_put(tun);
+	return &tun->socket;
+}
+EXPORT_SYMBOL_GPL(tun_get_socket);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);

include/linux/if_tun.h +14 -0

index 3f5fd52..404abe0 100644
@@ -86,4 +86,18 @@ struct tun_filter {
 	__u8   addr[0][ETH_ALEN];
 };
 
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
+struct socket *tun_get_socket(struct file *);
+#else
+#include <linux/err.h>
+#include <linux/errno.h>
+struct file;
+struct socket;
+static inline struct socket *tun_get_socket(struct file *f)
+{
+	return ERR_PTR(-EINVAL);
+}
+#endif /* CONFIG_TUN */
+#endif /* __KERNEL__ */
 #endif /* __IF_TUN_H */

Signature · 2 lines

paul moore
linux @ hp

Quoted 12 lines · Paul Moore

Quoted 11 lines · Michael S. Tsirkin

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and exports access to this socket to modules.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

Quoted 6 lines

Quoted 2 lines

First user of this interface will be vhost virtualization accelerator.

No comments on the code at this point - I'm just trying to understand the intended user right now which I'm assuming is the vhost-net bits you sent previously?

Yes - these now use raw socket,

Quoted 13 lines · Michael S. Tsirkin

Quoted 12 lines · Paul Moore

Quoted 11 lines · Michael S. Tsirkin

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and exports access to this socket to modules.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

First user of this interface will be vhost virtualization accelerator.

No comments on the code at this point - I'm just trying to understand the intended user right now which I'm assuming is the vhost-net bits you sent previously?

Yes - these now use raw socket,

More specifically, vhost would then be patched with:

drivers/vhost/net.c +0 -0

index aeffb3a..b54f9d6 100644

drivers/vhost/net.c +5 -0

+}
+
 static struct socket *get_socket(int fd)
 {
 	struct socket *sock;
 	sock = get_raw_socket(fd);
 	if (!IS_ERR(sock))
 		return sock;
+	sock = get_tun_socket(fd);
+	if (!IS_ERR(sock))
+		return sock;
 	return ERR_PTR(-ENOTSOCK);
 }
 
 static long vhost_net_set_socket(struct vhost_net *n, int fd)
 {
 	struct socket *sock, *oldsock = NULL;

Quoted 31 lines · Michael S. Tsirkin

Quoted 13 lines · Michael S. Tsirkin

Quoted 12 lines · Paul Moore

Quoted 11 lines · Michael S. Tsirkin

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and exports access to this socket to modules.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

First user of this interface will be vhost virtualization accelerator.

No comments on the code at this point - I'm just trying to understand the intended user right now which I'm assuming is the vhost-net bits you sent previously?

Yes - these now use raw socket,

More specifically, vhost would then be patched with:

drivers/vhost/net.c +0 -0

index aeffb3a..b54f9d6 100644
@@ -331,15 +331,26 @@ err:
 	return ERR_PTR(r);
 }
 

drivers/vhost/net.c err: · line 339

Quoted 6 lines

drivers/vhost/net.c +6 -0

+static struct socket *get_tun_socket(int fd)
+{
+	struct file *file = fget(fd);
+	if (!file)
+		return ERR_PTR(-EBADF);
+	return tun_get_socket(file);

This would leak a reference on file, if it happens not being a tun file

Quoted 3 lines · Paul Moore

Quoted 2 lines

No comments on the code at this point - I'm just trying to understand the intended user right now which I'm assuming is the vhost-net bits you sent previously

More specifically, vhost would then be patched with:

  diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index aeffb3a..b54f9d6 100644
  --- a/drivers/vhost/net.c
  +++ b/drivers/vhost/net.c
  @@ -331,15 +331,26 @@ err:
        return ERR_PTR(r);
  }

  +static struct socket *get_tun_socket(int fd)
  +{
  +       struct file *file = fget(fd);
  +       if (!file)
  +               return ERR_PTR(-EBADF);
  +       return tun_get_socket(file);
  +}
  +
  static struct socket *get_socket(int fd)

  {
        struct socket *sock;
        sock = get_raw_socket(fd);

        if (!IS_ERR(sock))
                return sock;

+       sock = get_tun_socket(fd);
  +       if (!IS_ERR(sock))
  +               return sock;
        return ERR_PTR(-ENOTSOCK);
  }

  static long vhost_net_set_socket(struct vhost_net *n, int fd) {
        struct socket *sock, *oldsock = NULL;

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification. First user of this interface will be vhost virtualization accelerator.

Quoted 3 lines · Michael S. Tsirkin

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification. First user of this interface will be vhost virtualization accelerator.

vhost injects packet into physical device, what is the use case of vhost injecting packet into the host network stack?

Or.

Quoted 2 lines · Or Gerlitz

vhost injects packets into physical device, what is the use case of vhost injecting packets into the host network stack?

The case where the user requires bridging, typically.

Quoted 6 lines · Michael S. Tsirkin

Quoted 2 lines · Or Gerlitz

vhost injects packets into physical device, what is the use case of vhost injecting packets into the host network stack?

The case where the user requires bridging, typically.

So you want to support a scheme where someone wants to attach vhost to a bridge? why not just telling these users to just set their vhost on top of veth couple, such that one veth device is added to a bridge as interface and a vhost instance is tied to the other veth device?

Or.

That's already possible. However virtualization users are familiar with configuring the tun device, and tun has grown virtualization-specific extensions, so I don't see a reason not to accomodate these uses

Quoted 4 lines · Michael S. Tsirkin

That's already possible. However virtualization users are familiar with configuring the tun device, and tun has grown virtualization-specific extensions, so I don't see a reason not to accomodate these uses

Today packets are written/read from/to Qemu to/from tun device, how would the use case with vhost will look like?

Is this the user setting an uplink NIC + bridge + per VM tun device but the packets will go from/to virtio-net in the guest kernel to/from vhost in the host kernel and then from/to vhost to/from tun? so eventually no packets will be seen by the qemu process? I don't see what these scheme buys people, I got very much confused.

Or.

Quoted 1 line

how would the use case with vhost will look like?

- Configure bridge and tun using existing scripts
- pass tun fd to vhost via an ioctl
- vhost calls tun_get_socket
- from this point, guest networking just goes faster

A lot of people have asked for tun support in vhost, because qemu currently uses tun. With this scheme existing code and scripts can be used to configure both tun and bridge. You also can utilize virtualization-specific features in tun.

Quoted 2 lines

A lot of people have asked for tun support in vhost, because qemu currently uses tun. With this scheme existing code and scripts can be used to configure both tun and bridge. You also can utilize virtualization-specific features in tun.

Tun has code to support some virtualization-specific features, however, it has also some inherent problems, I think, for example, you don't know over which NIC eventually a packet will be sent and as such, the feature advertising to the guest (virtio-net) NIC is problematic, for example, TSO. With vhost, since you are directly attached to a NIC and assuming its a PF or VF NIC and not something like macvlan/veth you can actually know what features are supported by this NIC.

TSO is not a problem because we provide a software fallback when the hardware does not support it. So guests should always enable TSO if they support it and not worry about the physical NIC.

Yes, I am aware that GSO can take action and so software segmentation is / can be done when the HW isn't capable of doing so (and I assume the same can go for checksum). I assume that by "we provide" you mean the core networking code, correct? in what level? I assume its not the TCP one, since this is not applicable a tun/bridge scheme. Simper example would be the vm nic MTU... with vhost attached directly to a nic with packet socket you can learn/control it all, where when tun/bridge is used, how can you tell?

Quoted 5 lines · Michael S. Tsirkin

Quoted 1 line

how would the use case with vhost will look like?

- Configure bridge and tun using existing scripts
- pass tun fd to vhost via an ioctl
- vhost calls tun_get_socket
- from this point, guest networking just goes faster

let me see I am with you:

1. vhost gets from user space through ioctl packet socket fd OR tun fd - but never both

2. for packet socket fd
VM.TX is translated by vhost to sendmsg which goes through the NIC NIC RX makes the fd poll to signal and then recvmsg is called on the fd, then vhost places the packet in a virtq

3. for tun fd
VM.TX is translated by vhost to sendmsg which is translated by tun to netif_rx which is then handled by the bridge
NIC RX goes to the bridge which xmits the packet a tun interface, now what makes tun provide this packet to vhost and how it is done?

Quoted 5 lines

A lot of people have asked for tun support in vhost, because qemu currently uses tun. With this scheme existing code and scripts can be used to configure both tun and bridge. You also can utilize virtualization-specific features in tun.

Tun has code to support some virtualization-specific features, however, it has also some inherent problems, I think, for example, you don't know over which NIC eventually a packet will be sent and as such, the feature advertising to the guest (virtio-net) NIC is problematic, for example,
TSO. With vhost, since you are directly attached to a NIC and assuming its a PF or VF NIC and not something like macvlan/veth you can actually know what features are supported by this NIC.

Or.

Quoted 5 lines

3. for tun fd
VM.TX is translated by vhost to sendmsg which is translated by tun to netif_rx which is then handled by the bridge
NIC RX  goes to the bridge which xmits the packet a tun interface, now what makes tun provide this packet to vhost and how it is done?

Same as above. vhost polls tun and calls recvmsg on the socket

Quoted 5 lines · Michael S. Tsirkin

Quoted 5 lines

3. for tun fd
VM.TX is translated by vhost to sendmsg which is translated by tun to netif_rx which is then handled by the bridge
NIC RX  goes to the bridge which xmits the packet a tun interface, now what makes tun provide this packet to vhost and how it is done?

Quoted 1 line

Same as above. vhost polls tun and calls recvmsg on the socket

no, correct if I'm wrong, but recvmsg calls tun_do_read and the later calls tun_put_user to the packet goes to user space and not into the virtq

Or.

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace.

This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and message flags MSG_TRUNC and MSG_DONTWAIT, and exports access to this socket to modules. Regular read/write behaviour is unchanged.

This way, code using raw sockets to inject packets into a physical device, can support injecting packets into host network stack almost without modification.

First user of this interface will be vhost virtualization accelerator.

Signed-off-by Michael S. Tsirkin <[email protected]>