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: <7249.1378490193@death.nxdomain>
Date:	Fri, 06 Sep 2013 10:56:33 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Marcelo Ricardo Leitner <mleitner@...hat.com>
cc:	netdev@...r.kernel.org, naleksan@...hat.com, andy@...yhouse.net
Subject: Re: [PATCH net] bonding: Avoid possible de-sync with arp_validate

Marcelo Ricardo Leitner <mleitner@...hat.com> wrote:

>Hi Dave,
>
>Please queue this one for -stable trees too.
>
>Thanks.
>
>---8<---
>
>As bond_store_arp_validation and bond_store_arp_interval doesn't
>deal with each other, we can't chain both at bond_open, otherwise
>we are open to this de-sync state, steps in sequence:
>- bond is down
>- arp_interval = 0
>- arp_validate = 1 or 2
>- bond is up
>- arp_interval = 1
>
>This would lead to bond issuing ARP requests but never listening
>to the replies, because the tap wasn't attached. After reaching
>this state, while bond is up, setting arp_validate won't help
>as it only acts if needed.

	You need to sign off you patch.

> drivers/net/bonding/bond_main.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 39e5b1c..805d098 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -3180,11 +3180,10 @@ static int bond_open(struct net_device *bond_dev)
> 	if (bond->params.miimon)  /* link check interval, in milliseconds. */
> 		queue_delayed_work(bond->wq, &bond->mii_work, 0);
>
>-	if (bond->params.arp_interval) {  /* arp interval, in milliseconds. */
>+	if (bond->params.arp_interval)    /* arp interval, in milliseconds. */
> 		queue_delayed_work(bond->wq, &bond->arp_work, 0);
>-		if (bond->params.arp_validate)
>-			bond->recv_probe = bond_arp_rcv;
>-	}
>+	if (bond->params.arp_validate)
>+		bond->recv_probe = bond_arp_rcv;

	Won't this set the recv_probe when arp_interval is 0 (disabled)?
That's going to make bonding look at a bunch of traffic it's not going
to do anything with.

	Why is this better than having bonding_store_arp_interval set
recv_probe if arp_validate is set when it queues the arp_work?  And,
presumably, clear the recv_probe if arp_interval is being cleared.

	-J

> 	if (bond->params.mode == BOND_MODE_8023AD) {
> 		queue_delayed_work(bond->wq, &bond->ad_work, 0);
>-- 
>1.8.3.1
>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ