From: Jason Wang <jasowang-H+wXaHxf7aLQT0dZR+AlfA@public•gmane.org>
To: "Michael S. Tsirkin" <mst-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: Fri, 28 Nov 2014 08:15:32 +0008 [thread overview]
Message-ID: <1417162052.5822.0@smtp.corp.redhat.com> (raw)
In-Reply-To: <1417118789-18231-38-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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?
>
> + 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
next prev parent reply other threads:[~2014-11-28 8:07 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1417118789-18231-1-git-send-email-mst@redhat.com>
2014-11-27 20:09 ` [PATCH v6 15/46] virtio_net: v1.0 endianness Michael S. Tsirkin
2014-11-27 20:09 ` [PATCH v6 23/46] virtio_net: pass vi around Michael S. Tsirkin
2014-11-27 20:09 ` [PATCH v6 24/46] virtio_net: get rid of virtio_net_hdr/skb_vnet_hdr Michael S. Tsirkin
2014-11-28 8:30 ` Jason Wang
2014-11-27 20:09 ` [PATCH v6 25/46] virtio_net: stricter short buffer length checks Michael S. Tsirkin
2014-11-28 8:31 ` Jason Wang
2014-11-27 20:10 ` [PATCH v6 26/46] virtio_net: bigger header when VERSION_1 is set Michael S. Tsirkin
2014-11-28 8:31 ` Jason Wang
2014-11-27 20:10 ` [PATCH v6 27/46] virtio_net: enable v1.0 support Michael S. Tsirkin
2014-11-27 20:10 ` [PATCH v6 28/46] vhost: make features 64 bit Michael S. Tsirkin
2014-11-28 8:32 ` Jason Wang
2014-11-27 20:10 ` [PATCH v6 29/46] vhost: add memory access wrappers Michael S. Tsirkin
2014-11-28 8:35 ` Jason Wang
2014-11-27 20:10 ` [PATCH v6 30/46] vhost/net: force len for TX to host endian Michael S. Tsirkin
2014-11-28 8:36 ` Jason Wang
2014-11-27 20:10 ` [PATCH v6 31/46] vhost: virtio 1.0 endian-ness support Michael S. Tsirkin
2014-11-27 20:10 ` [PATCH v6 32/46] vhost/net: virtio 1.0 byte swap Michael S. Tsirkin
2014-11-27 20:10 ` [PATCH v6 33/46] vhost/net: larger header for virtio 1.0 Michael S. Tsirkin
2014-11-28 8:38 ` Jason Wang
2014-11-27 20:10 ` [PATCH v6 34/46] virtio_net: disable mac write " Michael S. Tsirkin
2014-11-28 8:40 ` Jason Wang
2014-11-29 17:28 ` Michael S. Tsirkin
2014-11-27 20:10 ` [PATCH v6 35/46] vhost/net: enable " Michael S. Tsirkin
2014-11-27 20:10 ` [PATCH v6 36/46] vhost/net: suppress compiler warning 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 [this message]
[not found] ` <1417162052.5822.0-LLcwxoN42L4NLKR9yMNcA1aTQe2KTcn/@public.gmane.org>
2014-11-29 17:17 ` Michael S. Tsirkin
2014-11-27 20:11 ` [PATCH v6 38/46] tun: drop most type defines Michael S. Tsirkin
2014-11-28 8:09 ` Jason Wang
2014-11-29 17:23 ` Michael S. Tsirkin
2014-11-27 20:11 ` [PATCH v6 39/46] tun: add VNET_LE flag Michael S. Tsirkin
2014-11-27 20:11 ` [PATCH v6 40/46] tun: TUN_VNET_LE support, fix sparse warnings for virtio headers Michael S. Tsirkin
2014-11-28 8:19 ` Jason Wang
2014-11-27 20:11 ` [PATCH v6 41/46] macvtap: TUN_VNET_HDR support Michael S. Tsirkin
2014-11-28 8:24 ` Jason Wang
2014-11-27 20:11 ` [PATCH v6 45/46] vhost/scsi: partial virtio 1.0 support Michael S. Tsirkin
2014-11-27 20:11 ` [PATCH v6 46/46] af_packet: virtio 1.0 stubs 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=1417162052.5822.0@smtp.corp.redhat.com \
--to=jasowang-h+wxahxf7alqt0dzr+alfa@public$(echo .)gmane.org \
--cc=ben-/+tVBieCtBitmTQ+vhA3Yw@public$(echo .)gmane.org \
--cc=cornelia.huck-tA70FqPdS9bQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=dahi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public$(echo .)gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public$(echo .)gmane.org \
--cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public$(echo .)gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=mst-H+wXaHxf7aLQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=nab-IzHhD5pYlfBP7FQvKIMDCQ@public$(echo .)gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=rusty-8fk3Idey6ehBDgjK7y7TUQ@public$(echo .)gmane.org \
--cc=therbert-hpIqsD4AKlfQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=thuth-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public$(echo .)gmane.org \
--cc=wuzhy-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public$(echo .)gmane.org \
--cc=xii-hpIqsD4AKlfQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=yamato-H+wXaHxf7aLQT0dZR+AlfA@public$(echo .)gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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