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] [day] [month] [year] [list]
Date:	Thu, 5 May 2011 00:49:11 -0700
From:	"Zou, Yi" <yi.zou@...el.com>
To:	Michał Mirosław <mirq-linux@...e.qmqm.pl>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"devel@...n-fcoe.org" <devel@...n-fcoe.org>
Subject: RE: [PATCH] [RFC] vlan: fix updating wanted_features for vlan device

> 
> On Wed, May 04, 2011 at 05:48:42PM -0700, Yi Zou wrote:
> > commit 8a0427b "vlan: convert VLAN devices to use ndo_fix_features()"
> converts the
> > vlan to support ndo_fix_features. However, the wanted_features is not
> updated
> > for the vlan device, causing real_dev->features not be populated to the
> vlan
> > device when real_dev->features are changed by the driver through
> FEAT_CHANGE.
> > This is breaking FCoE related netdev feature flags on vlan devices. Add
> updating
> > wanted_features to vlan_transfer_features() so
> netdev_get_wanted_features() will
> > can get the updated wanted feature flags for vlan device properly.
> 
> Can you describe the situation further? There might be problems if device
> changes its vlan_features after creation of VLAN devices on top
> (bonding?).

Not sure for bonding, I noticed this when creating FCoE instance on a vlan
Device on top of an Intel 82599 device. The real_dev is created with 
vlan_features set of related FCoE flags, e.g., NETIF_F_FCOE_MTU, NETIF_F_FCOE_CRC,
etc. However, the real_dev's features are not set w/ these FCoE flags till 
the FCoE protocol stack starts using FCoE when ndo_fcoe_enable() is called, 
where in the case of 82599's case, these flags are toggled on in netdev's 
features, and netdev_features_change() is called to populate to the upper 
vlan device since previously we do:

       vlandev->features &= ~dev->vlan_features;
       vlandev->features |= dev->features & dev->vlan_features; 

in vlan_transfer_features(). FCoE only checks the corresponding netdev features
(vlan or real_dev) passed in from user space as a interface name e.g., eth2.100,
to tell if, for example, FCOE_MTU is supported. Particularly for this case, there
is no change on vlan_features. 

> 
> dev->wanted_features is only what user wants to get and should not be
> changed
> by anything else.
Hmm...so my usage for that seems to be wrong if that's what wanted_features is
meant to be. Well, wanted_features in vlan is features & hw_features, if it stays,
then, it seems to me will never get changes from real_dev's features since 
netdev_get_wanted_features() won't get it to begin w/.

Also, note my RFC isn't complete either, as it only sets not clears previously
flags in wanted_features.

Thanks,
yi
> 
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ