netdev - Re: [PATCH net-next-2.6 0/5] bonding: Refactor, fix, and updates

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]

Message-ID: <2476.1218062950@death>
Date:	Wed, 06 Aug 2008 15:49:10 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Jeff Garzik <jgarzik@...ox.com>
cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next-2.6 0/5] bonding: Refactor, fix, and updates


	Jeff, are you still waiting for net-next-2.6 to settle before
forwarding patches?  It's been a couple of weeks since your last status
update, and I want check to see if I should resend the patches from this
series.

	Davem did ack the relevant patches.

From: Jay Vosburgh <fubar@...ibm.com>
To: netdev@...r.kernel.org
Cc: Jeff Garzik <jgarzik@...ox.com>, David Miller <davem@...emloft.net>
Subject: [PATCH net-next-2.6 0/5] bonding: Refactor, fix, and updates
Date: 	Wed,  2 Jul 2008 18:21:57 -0700

	Five patches for bonding; these apply to net-next-2.6.

	Patch 1 is a refactor of the MII monitor, similar to the previous
refactor of the ARP active-backup monitor.  It replaces the monolithic
monitor function that uses conditional locking with a two phase (inspect
and commit) approach with strict locking (RTNL) required only for the
commit phase (which is only called when things actually change).  The long
term goal here is to ultimately consolidate all monitors within a generic
framework.

	Patch 2 makes a change to the Infiniband slave removal processing
to avoid a system crash when removing the final slave via sysfs.

	Patches 3 - 5 provide support for allowing slaves to receive
traffic independently from the master, and require some explanation.

	The goal of the last three patches is to permit slaves to receive
incoming traffic independently from the master; there are legitimate
reasons for wanting to do so, e.g., LLDP.  There are two ways to implement
this: a special case within bonding (skb_bond_should_drop) that would
require a hard-coded list of protocols to pass through, or a generic
method, that modifies the packet receive logic within netif_receive_skb.
The latter method is what is presented here.

	Please apply patches 1 - 2, and review and apply or provide
feedback for patches 3 - 5.

	-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