netdev - Re: [PATCH 7/7] bnx2x: expose HW RX VLAN stripping toggle

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, 30 Aug 2011 22:08:41 +0200
From:	Michał Mirosław <mirqus@...il.com>
To:	Michal Schmidt <mschmidt@...hat.com>
Cc:	netdev@...r.kernel.org, vladz@...adcom.com, dmitry@...adcom.com,
	eilong@...adcom.com
Subject: Re: [PATCH 7/7] bnx2x: expose HW RX VLAN stripping toggle

W dniu 30 sierpnia 2011 21:30 użytkownik Michal Schmidt
<mschmidt@...hat.com> napisał:
> On 08/30/2011 08:27 PM, Michał Mirosław wrote:
>> It seems rather convoluted and unnecessary that you mirror
>> NETIF_F_HW_VLAN_RX in bp->flags
> This mirroring is for the benefit of functions called indirectly from
> bnx2x_set_features(). They cannot look at dev->features for
> NETIF_F_HW_VLAN_RX because it's not set before ->ndo_set_features() returns.

You can cheat in ndo_set_features in this case. Just set/clear
NETIF_F_HW_VLAN_RX bit in dev->features before you call those
functions (but please leave a comment there explaining why!). This is
allowed because if ndo_set_features fails it needs to fix
dev->features itself, and if it succeeds dev->features will be
replaced with exactly what was passed to ndo_set_features. So, unless
you need to check whether the VLAN stripping state changed in those
functions, then you can get rid of this copy.

>> and then also in fp->flags.  Are the
>> fp->flags strictly mirroring hardware state (as in: there is no way
>> the states can differ in any point in time where the flags are
>> tested)?
> Yes. This is the purpose of the second mirroring of the flag.
>> For this to be true, the two functions above need to be
>> called only without releasing a lock between them that is also taken
>> by receive handler.
> The flag propagates from bp->flags to fp->flags between unloading and
> reloading the NIC. The receive handler cannot run at the time.
>> Isn't there a flag in the rx descriptor of a
>> packet that says if VLAN was stripped? (All that flag keeping would be
>> unnecessary then.)
> There is no such flag, AFAIK.

Thanks for explanation!

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