netdev - Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <46AF4DEA.9050202@voltaire.com>
Date:	Tue, 31 Jul 2007 17:57:46 +0300
From:	Or Gerlitz <ogerlitz@...taire.com>
To:	"Michael S. Tsirkin" <mst@....mellanox.co.il>
CC:	netdev@...r.kernel.org, Roland Dreier <rdreier@...co.com>,
	fubar@...ibm.com, davem@...emloft.net,
	general@...ts.openfabrics.org
Subject: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for	the	bonding
 driver

Michael S. Tsirkin wrote:
>> Quoting Or Gerlitz <ogerlitz@...taire.com>:
>> Michael S. Tsirkin wrote:

>>> It's always wrong to copy symbols from another module without
>>> referencing it.
>> Its the --first-- time you make this comment,

> It's really a well known fact. That's where the crash
> with modprobe -r comes from, right?

no, the crash --only-- comes from the neighbour cleanup function being 
called while ipoib is now probed out of the kernel. The other symbols 
are not problematic. I got positive feedback that this --is-- the 
problem in the previous posts and from Roland during my Sonoma presentation.

>> please suggest a different approach,

> I don't know, really - if you want to access a module, you really must get
> a reference to it, or to the device.
> How about adding the module pointer to struct net_device?

I think there used to be there owner field of type struct module and it 
was removed... we will check that.

>> the relevant code is below.
> 
>> +static void bond_setup_by_slave(struct net_device *bond_dev,
>> +				struct net_device *slave_dev)
>> +{
>> +	bond_dev->hard_header	        = slave_dev->hard_header;
>> +	bond_dev->rebuild_header        = slave_dev->rebuild_header;
>> +	bond_dev->hard_header_cache	= slave_dev->hard_header_cache;
>> +	bond_dev->header_cache_update   = slave_dev->header_cache_update;
>> +	bond_dev->hard_header_parse	= slave_dev->hard_header_parse;
>> +
>> +	bond_dev->neigh_setup           = slave_dev->neigh_setup;
>> +
>> +	bond_dev->type		    = slave_dev->type;
>> +	bond_dev->hard_header_len   = slave_dev->hard_header_len;
>> +	bond_dev->addr_len	    = slave_dev->addr_len;
>> +
>> +	memcpy(bond_dev->broadcast, slave_dev->broadcast,
>> +		slave_dev->addr_len);
>> +}
>> +
> 
> Hmm, it seems that switching to hard_header_cache as I suggested won't help at all.

why? please clarify.

> I wonder: is bonding currently broken with devices that implement
> hard_header_cache/header_cache_update?

I don't think so. Note that bond_setup_by_slave is only called for 
slaves whose ether type is --not-- Ethernet.

Or.



-
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