netdev - Re: [PATCH] net: tuntap: Fix tun_net_fix

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]

Date:	Tue, 17 May 2011 17:00:29 +0200
From:	Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	netdev@...r.kernel.org, Herbert Xu <herbert@...dor.hengli.com.au>,
	Ben Hutchings <bhutchings@...arflare.com>,
	Shan Wei <shanwei@...fujitsu.com>
Subject: Re: [PATCH] net: tuntap: Fix tun_net_fix_features()

On Tue, May 17, 2011 at 05:54:28PM +0300, Michael S. Tsirkin wrote:
> On Tue, May 17, 2011 at 04:46:35PM +0200, Michał Mirosław wrote:
> > On Tue, May 17, 2011 at 05:29:43PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, May 17, 2011 at 10:19:54AM +0200, Michał Mirosław wrote:
> > > > tun->set_features are meant to limit not force the features.
[...]
> > > One thing that this will do though: previously, if
> > > ethtool disables offloads, then an application enables
> > > them, the application will have the last say.
> > > With this patch, the most conservative approach wins.
> > > Right?
> > 
> > Exactly.
> > 
> > On device creation, wanted_features default to all offloads
> > enabled, so unless an admin changes the flags, the application controls
> > what is enabled. This matters only when using persistent tun/tap and
> > admin and user are two different people. If the admin is using queues
> > and doesn't want to handle e.g. TSO packets (I'm not sure if they are
> > properly accounted in all queuing disciplines), then the feature should
> > not be enabled by user.
[...]
> Yes, with virtualization admin and the app are two different people
> usually.  The device doesn't have to be persistent though I think -
> what limits this to persistent devices?

Hmm. Nothing really. I just forgot about the virtualization case. You
usually will change the offloads just after device creation unless you're
testing or debugging something.

> I agree this behaviour seems more consistent, I just hope this change
> does not break any setups.

The only effect would be some performance drop on cases, where admin turned
off the offloads and they stay like that regardless of what user part does.

Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html