Re: [PATCH net-2.6] bonding: correctly process LACPDUs in non-linear skbs

[Jay Vosburgh <fubar@us.ibm.com>]

Andy Gospodarek <andy@greyhouse.net> wrote:

>
>It was recently brought to my attention that 802.3ad mode bonds would no
>longer form when using some network hardware after a driver update.
>After snooping around I realized that the particular hardware was using
>page-based skbs and found that skb->data did not contain a valid LACPDU
>as it wasn't stored there.  That explained the inability to form an
>802.3ad-based bond.
>
>This patch fixes the issue in my tests and should be applied to 2.6.36
>and as far back as anyone cares to add it to stable.
>
>Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
>Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.
>
>Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>CC: Alexander Duyck <alexander.h.duyck@intel.com>
>CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
>CC: stable@kernel.org

	Did you by any chance also test balance-alb mode?  Inspection
suggests that rlb_arp_recv may suffer from the same problem.

	If you agree, could you add that to the patch and resubmit it?

	Either way, the patch looks good.

	-J

Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>


>---
> drivers/net/bonding/bond_3ad.c |    3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 822f586..0ddf4c6 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -2466,6 +2466,9 @@ int bond_3ad_lacpdu_recv(struct sk_buff *skb, struct net_device *dev, struct pac
> 	if (!(dev->flags & IFF_MASTER))
> 		goto out;
>
>+	if (!pskb_may_pull(skb, sizeof(struct lacpdu)))
>+		goto out;
>+
> 	read_lock(&bond->lock);
> 	slave = bond_get_slave_by_dev((struct bonding *)netdev_priv(dev),
> 					orig_dev);
>-- 
>1.7.0.1
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html