netdev - Re: [patch net-next] net: increase the size of priv_flags and add IFF_OVS

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6280.1282632485@death>
Date:	Mon, 23 Aug 2010 23:48:05 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	David Miller <davem@...emloft.net>
cc:	horms@...ge.net.au, netdev@...r.kernel.org, jesse@...ira.com
Subject: Re: [patch net-next] net: increase the size of priv_flags and add IFF_OVS_DATAPATH

David Miller <davem@...emloft.net> wrote:

>From: Simon Horman <horms@...ge.net.au>
>Date: Tue, 24 Aug 2010 11:26:41 +0900
>
>> IFF_OVS_DATAPATH is a place-holder for the Open vSwitch datapath
>> which I am preparing to submit for merging.
>> 
>> As all 16 bits of priv_flags are already assigned flags, also increase
>> the size of priv_flags to 32 bits.
>> 
>> Unfortunately, by my calculations this increases the size of
>> struct net_device by 4 bytes on 32bit architectures and
>> 8 bytes on 64 bit architectures. I couldn't see an obvious
>> way to avoid that.
>> 
>> Cc: Jesse Gross <jesse@...ira.com>
>> Signed-off-by: Simon Horman <horms@...ge.net.au>
>
>I can't think of a better way out of this, so applied for now.
>
>Maybe somehow some of those bonding specific flags can get put
>down into the bonding private structure.  However, that might
>not be possible if the sole reason those live in ->priv_flags
>is to allow tests of the flags outside of the bonding code.

	That is indeed the case: it's to permit the flags to be tested
primarily in the netif_receive_skb path (inside __skb_bond_should_drop)
without calling into bonding via a hook or the like.  There's also one
check in fcoe to not support fcoe over a subset of bonding modes, from
the looks of it.

	I don't think the bonding tests could be rolled up into a
dev->rx_handler, either, because the bonding stuff has to happen before
any delivery attempts (it may affect skb->dev or packet delivery).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
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