netdev - Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure

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:	Thu, 10 Jan 2013 14:01:11 -0500
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	netdev@...r.kernel.org, davem@...emloft.net, stephen@...hat.com,
	bridge@...ts.linux-foundation.org, shmulik.ladkani@...il.com,
	mst@...hat.com
Subject: Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure

On 01/10/2013 01:36 PM, Stephen Hemminger wrote:
> This patch has some minor whitespace and spelling errors:
>
> WARNING: line over 80 characters
> #429: FILE: net/bridge/br_private.h:205:
> +static inline struct net_bridge_port *vlans_to_port(struct net_port_vlans *vlans)
>
> ERROR: trailing whitespace
> #432: FILE: net/bridge/br_private.h:208:
> +       $
>
> WARNING: please, no spaces at the start of a line
> #432: FILE: net/bridge/br_private.h:208:
> +       $
>
> +/* Must be protected by RTNL */
> +static void br_vlan_del(struct net_bridge_vlan *vlan)
>
> +	/* Drop the self-ref to trigger descrution. */
>                                          ^^^^^^^^^^
>

sorry, will fix.  I thought I ran everything through checkpatch.  I'll 
re-run them.

> Also, the data structure vlan's seems inverted. Why do you keep a hash list
> of vlan's and then a bitmap of ports. Seems more natural to just put a bitmap
> on each port that has vlan filtering rather than introducing yet another list
> to manage.
>

I originally had it this way.  I found that it wasted space and made 
other things more difficult to do.  For instance, to do egress policy, I 
would have needed another bitmap of vlans... With 4096 vlans, that's
512 bytes per port (1024 with policy).

I could probably remove the per-port list.  It would make 2 things a 
little harder:
   1) detecting if the port has any vlan info at all.
   2) dumping the vlan information

I could pursue this if you think it'll be better.

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