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 21:30:11 +0200
From:	Michal Schmidt <mschmidt@...hat.com>
To:	Michał Mirosław <mirqus@...il.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

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.

> 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.

Michal
--
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