From: Jason Wang <jasowang@redhat.com>
To: mst@redhat.com, pmoore@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: mprivozn@redhat.com, Jason Wang <jasowang@redhat.com>
Subject: [PATCH net-next rfc 0/2] Allow unpriveledge user to disable tuntap queue
Date: Tue, 11 Dec 2012 19:03:45 +0800 [thread overview]
Message-ID: <1355223827-57290-1-git-send-email-jasowang@redhat.com> (raw)
This series is an rfc that tries to solve the issue that the queues of tuntap
could not be disabled/enabled by unpriveledged user. This is needed for
unpriveledge userspace such as qemu since guest may change the number of queues
at any time, qemu needs to configure the tuntap to disable/enable a specific
queue.
Instead of introducting new flag/ioctls, this series tries to re-use the current
TUNSETQUEUE and IFF_ATTACH_QUEUE/IFF_DETACH_QUEUE. After this change,
IFF_DETACH_QUEUE is used to disable a specific queue instead of detaching all
its state from tuntap. IFF_ATTACH_QUEUE is used to do: 1) creating new queue to
a tuntap device, in this situation, previous DAC check is still done. 2)
re-enable the queue previously disabled by IFF_DETACH_QUEUE, in this situation,
we can bypass some checking when we do during queue creating (the check need to
be done here needs discussion.
Management software (such as libvirt) then can do:
- TUNSETIFF to creating device and queue 0
- TUNSETQUEUE to create the rest of queues
- Passing them to unpriveledge userspace (such as qemu)
Then the unpriveledge userspace can enable and disable a specific queue through
IFF_ATTACH_QUEUE and IFF_DETACH_QUEUE.
This is done by introducing a enabled flags were used to notify whether the
queue is enabled, and tuntap only send/receive packets when it was enabled.
Please comment, thanks!
Jason Wang (2):
tuntap: forbid calling TUNSETQUEUE for a persistent device with no
queues
tuntap: allow unpriveledge user to enable and disable queues
drivers/net/tun.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 73 insertions(+), 5 deletions(-)
next reply other threads:[~2012-12-11 11:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-11 11:03 Jason Wang [this message]
2012-12-11 11:03 ` [PATCH net-next rfc 1/2] tuntap: forbid calling TUNSETQUEUE for a persistent device with no queues Jason Wang
2012-12-11 11:03 ` [PATCH net-next rfc 2/2] tuntap: allow unpriveledge user to enable and disable queues Jason Wang
2012-12-11 12:30 ` Michael S. Tsirkin
2012-12-12 3:34 ` Jason Wang
2012-12-11 12:46 ` [PATCH net-next rfc 0/2] Allow unpriveledge user to disable tuntap queue Michael S. Tsirkin
2012-12-12 3:29 ` Jason Wang
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=1355223827-57290-1-git-send-email-jasowang@redhat.com \
--to=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mprivozn@redhat.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pmoore@redhat.com \
/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).