linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jason Wang <jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
	cornelia.huck-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org,
	rusty-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org,
	nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org,
	pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	thuth-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
	dahi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
	Zhi Yong Wu
	<wuzhy-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>,
	Herbert Xu
	<herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>,
	Tom Herbert <therbert-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Masatake YAMATO <yamato-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Xi Wang <xii-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v6 37/46] tun: move internal flag defines out of uapi
Date: Sat, 29 Nov 2014 19:17:18 +0200	[thread overview]
Message-ID: <20141129171718.GA22746@redhat.com> (raw)
In-Reply-To: <1417162052.5822.0-LLcwxoN42L4NLKR9yMNcA1aTQe2KTcn/@public.gmane.org>

On Fri, Nov 28, 2014 at 08:15:32AM +0008, Jason Wang wrote:
> 
> 
> On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >TUN_ flags are internal and never exposed
> >to userspace. Any application using it is almost
> >certainly buggy.
> >
> >Move them out to tun.c, we'll remove them in follow-up patches.
> >
> >Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >---
> > include/uapi/linux/if_tun.h | 16 ++--------
> > drivers/net/tun.c           | 74
> >++++++++++++++-------------------------------
> > 2 files changed, 26 insertions(+), 64 deletions(-)
> >
> >diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> >index e9502dd..277a260 100644
> >--- a/include/uapi/linux/if_tun.h
> >+++ b/include/uapi/linux/if_tun.h
> >@@ -22,21 +22,11 @@
> > /* Read queue size */
> > #define TUN_READQ_SIZE	500
> >-
> >-/* TUN device flags */
> >-#define TUN_TUN_DEV 	0x0001	
> >-#define TUN_TAP_DEV	0x0002
> >+/* TUN device type flags: deprecated. Use IFF_TUN/IFF_TAP instead. */
> >+#define TUN_TUN_DEV 	IFF_TUN
> >+#define TUN_TAP_DEV	IFF_TAP
> > #define TUN_TYPE_MASK   0x000f
> >-#define TUN_FASYNC	0x0010
> >-#define TUN_NOCHECKSUM	0x0020
> >-#define TUN_NO_PI	0x0040
> >-/* This flag has no real effect */
> >-#define TUN_ONE_QUEUE	0x0080
> >-#define TUN_PERSIST 	0x0100	
> >-#define TUN_VNET_HDR 	0x0200
> >-#define TUN_TAP_MQ      0x0400
> >-
> > /* Ioctl defines */
> > #define TUNSETNOCSUM  _IOW('T', 200, int)  #define TUNSETDEBUG
> >_IOW('T', 201, int) diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >index 9dd3746..bc89d07 100644
> >--- a/drivers/net/tun.c
> >+++ b/drivers/net/tun.c
> >@@ -103,6 +103,21 @@ do {								\
> > } while (0)
> > #endif
> >+/* TUN device flags */
> >+
> >+/* IFF_ATTACH_QUEUE is never stored in device flags,
> >+ * overload it to mean fasync when stored there.
> >+ */
> >+#define TUN_FASYNC	IFF_ATTACH_QUEUE
> >+#define TUN_NO_PI	IFF_NO_PI
> >+/* This flag has no real effect */
> >+#define TUN_ONE_QUEUE	IFF_ONE_QUEUE
> >+#define TUN_PERSIST 	IFF_PERSIST
> >+#define TUN_VNET_HDR 	IFF_VNET_HDR
> >+#define TUN_TAP_MQ      IFF_MULTI_QUEUE
> >+
> >+#define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
> >+		      IFF_MULTI_QUEUE)
> > #define GOODCOPY_LEN 128
> > #define FLT_EXACT_COUNT 8
> >@@ -1521,32 +1536,7 @@ static struct proto tun_proto = {
> > static int tun_flags(struct tun_struct *tun)
> > {
> >-	int flags = 0;
> >-
> >-	if (tun->flags & TUN_TUN_DEV)
> >-		flags |= IFF_TUN;
> >-	else
> >-		flags |= IFF_TAP;
> >-
> >-	if (tun->flags & TUN_NO_PI)
> >-		flags |= IFF_NO_PI;
> >-
> >-	/* This flag has no real effect.  We track the value for backwards
> >-	 * compatibility.
> >-	 */
> >-	if (tun->flags & TUN_ONE_QUEUE)
> >-		flags |= IFF_ONE_QUEUE;
> >-
> >-	if (tun->flags & TUN_VNET_HDR)
> >-		flags |= IFF_VNET_HDR;
> >-
> >-	if (tun->flags & TUN_TAP_MQ)
> >-		flags |= IFF_MULTI_QUEUE;
> >-
> >-	if (tun->flags & TUN_PERSIST)
> >-		flags |= IFF_PERSIST;
> >-
> >-	return flags;
> >+	return tun->flags & (TUN_FEATURES | IFF_PERSIST | IFF_TUN | IFF_TAP);
> > }
> >   static ssize_t tun_show_flags(struct device *dev, struct
> >device_attribute *attr,
> >@@ -1706,28 +1696,8 @@ static int tun_set_iff(struct net *net, struct file
> >*file, struct ifreq *ifr)
> > 	tun_debug(KERN_INFO, tun, "tun_set_iff\n");
> >-	if (ifr->ifr_flags & IFF_NO_PI)
> >-		tun->flags |= TUN_NO_PI;
> >-	else
> >-		tun->flags &= ~TUN_NO_PI;
> >-
> >-	/* This flag has no real effect.  We track the value for backwards
> >-	 * compatibility.
> >-	 */
> >-	if (ifr->ifr_flags & IFF_ONE_QUEUE)
> >-		tun->flags |= TUN_ONE_QUEUE;
> >-	else
> >-		tun->flags &= ~TUN_ONE_QUEUE;
> >-
> >-	if (ifr->ifr_flags & IFF_VNET_HDR)
> >-		tun->flags |= TUN_VNET_HDR;
> >-	else
> >-		tun->flags &= ~TUN_VNET_HDR;
> >-
> >-	if (ifr->ifr_flags & IFF_MULTI_QUEUE)
> >-		tun->flags |= TUN_TAP_MQ;
> >-	else
> >-		tun->flags &= ~TUN_TAP_MQ;
> >+	tun->flags = (tun->flags & ~TUN_FEATURES) |
> >+		(ifr->ifr_flags & TUN_FEATURES);
> > 	/* Make sure persistent devices do not get stuck in
> > 	 * xoff state.
> >@@ -1890,9 +1860,11 @@ static long __tun_chr_ioctl(struct file *file,
> >unsigned int cmd,
> > 	if (cmd == TUNGETFEATURES) {
> > 		/* Currently this just means: "what IFF flags are valid?".
> > 		 * This is needed because we never checked for invalid flags on
> >-		 * TUNSETIFF. */
> >-		return put_user(IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE |
> >-				IFF_VNET_HDR | IFF_MULTI_QUEUE,
> >+		 * TUNSETIFF.  Why do we report IFF_TUN and IFF_TAP which are
> >+		 * not legal for TUNSETIFF here?  It's probably a bug, but it
> >+		 * doesn't seem to be worth fixing.
> >+		 */
> 
> The question is not very clear. IFF_TUN and IFF_TAP are legal for
> ifr.ifr_flags during TUNSETIFF. No?


Absolutely. I'm not sure what I meant anymore. I will drop this chunk -
either by replacing this patch if I have to post another version, or
by a separate patch if I don't.

> >
> >+		return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
> > 				(unsigned int __user*)argp);
> > 	} else if (cmd == TUNSETQUEUE)
> > 		return tun_set_queue(file, &ifr);
> >-- 
> >MST
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-11-29 17:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1417118789-18231-1-git-send-email-mst@redhat.com>
2014-11-27 20:08 ` [PATCH v6 07/46] virtio: add virtio 1.0 feature bit Michael S. Tsirkin
2014-11-27 20:08 ` [PATCH v6 08/46] virtio: memory access APIs Michael S. Tsirkin
2014-11-27 20:08 ` [PATCH v6 12/46] virtio: set FEATURES_OK Michael S. Tsirkin
2014-11-27 20:09 ` [PATCH v6 15/46] virtio_net: v1.0 endianness Michael S. Tsirkin
2014-11-27 20:09 ` [PATCH v6 16/46] virtio_blk: v1.0 support Michael S. Tsirkin
2014-11-27 20:10 ` [PATCH v6 37/46] tun: move internal flag defines out of uapi Michael S. Tsirkin
     [not found]   ` <1417118789-18231-38-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-11-28  8:07     ` Jason Wang
     [not found]       ` <1417162052.5822.0-LLcwxoN42L4NLKR9yMNcA1aTQe2KTcn/@public.gmane.org>
2014-11-29 17:17         ` Michael S. Tsirkin [this message]
2014-11-27 20:11 ` [PATCH v6 39/46] tun: add VNET_LE flag Michael S. Tsirkin
2014-11-27 20:11 ` [PATCH v6 44/46] virtio_scsi: export to userspace Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141129171718.GA22746@redhat.com \
    --to=mst-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org \
    --cc=cornelia.huck-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
    --cc=dahi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org \
    --cc=jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=rusty-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org \
    --cc=therbert-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=thuth-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=wuzhy-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=xii-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=yamato-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).