linux-kernel - Re: [RFC 2/4] tuntap: Publish tuntap maximum number of queues as module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140820111724.GE17371@redhat.com>
Date:	Wed, 20 Aug 2014 13:17:24 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Pankaj Gupta <pagupta@...hat.com>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, davem@...emloft.net, jasowang@...hat.com,
	dgibson@...hat.com, vfalico@...il.com, edumazet@...gle.com,
	vyasevic@...hat.com, hkchu@...gle.com, wuzhy@...ux.vnet.ibm.com,
	xemul@...allels.com, therbert@...gle.com,
	bhutchings@...arflare.com, xii@...gle.com,
	stephen@...workplumber.org
Subject: Re: [RFC 2/4] tuntap: Publish tuntap maximum number of queues as
 module_param

On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote:
> Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@...hat.com wrote:
> > This patch publishes maximum number of tun/tap queues allocated as a
> > read_only module parameter which a user space application like libvirt
> > can make use of to limit maximum number of queues. Value of read_only
> > module parameter can be writable only at module load time. If no value is set
> > at module load time a default value 256 is used which is equal to maximum number
> > of vCPUS allowed by KVM.
> >
> > Administrator can specify maximum number of queues only at the driver
> > module load time.
> >
> >Signed-off-by: Pankaj Gupta <pagupta@...hat.com>
> >---
> > drivers/net/tun.c |   13 +++++++++++--
> > 1 files changed, 11 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >index acaaf67..1f518e2 100644
> >--- a/drivers/net/tun.c
> >+++ b/drivers/net/tun.c
> >@@ -119,6 +119,9 @@ struct tap_filter {
> > 
> > #define TUN_FLOW_EXPIRE (3 * HZ)
> > 
> >+static int max_tap_queues = MAX_TAP_QUEUES;
> >+module_param(max_tap_queues, int, S_IRUGO);
> 
> Please do not introduce new module paramaters. Please other ways to
> interchange values with userspace.

I suggested this initially, but thinking more about it, I agree.

It's a global limit (necessary to limit memory utilization by
userspace), but it should be possible to change it
after module load.

Additionally, userspace that has the FD should be able to
retrieve the value without guessing that the FD is
for the tun device (and not e.g. macvtap).
To retrieve the value, an ioctl is probably the
cleanest approach.

To set it, how about a sysctl? I think the limit can also apply to
all devices, not just tun.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/