netdev - Re: [PATCH RFC] net/bonding: announce fail-over for the active-backup mode

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

Message-ID: <4843CDF8.5010200@voltaire.com>
Date:	Mon, 02 Jun 2008 13:39:52 +0300
From:	Or Gerlitz <ogerlitz@...taire.com>
To:	Jay Vosburgh <fubar@...ibm.com>
CC:	Jeff Garzik <jgarzik@...ox.com>, netdev@...r.kernel.org
Subject: Re: [PATCH RFC] net/bonding: announce fail-over for the active-backup
 mode

Jay Vosburgh wrote:
> 	I'm suggesting you do exactly that: release the locks, do your
> stuff, then reacquire the locks.
OK
> 	I took a look, and I think this is how it stands: I recently
> refactored the active-backup ARP monitor, and I believe that all of its
> calls are now correct; this would have been the difficult one to fix, so
> you timed this just right.  The load-balance ARP monitor is still wrong,
> but you don't care about that one since it isn't used for active-backup
> mode.
sounds like I am lucky.
> 	I think the only cases that will require fixing for you are the
> bond_release and bond_release_all.
>
> 	For bond_release, there are two calls to change_active: one sets
> it to NULL, and the second sets to to a slave.  The first of those calls
> has nominally incorrect locking; the second has proper locking.
> Changing the first call to mimic the methodology of the second call
> should be pretty straightforward.  Alternately, if your notifier doesn't
> want to log "change to nothing" events (i.e., put it inside the "if
> (new_active)" block), then you could probably get away with not fixing
> the first call.
>
> 	For bond_release_all, there's just one call, and it sets the
> current slave to NULL (and then goes off and frees all of the slaves).
> The same caveats from the bond_release case apply here.

Thanks for this deep dive and guidance. I don't think there's a need to 
deliver "change to nothing" event and as such I took the approach of 
setting this event to happen only (under the acrtive-backup mode AND) 
when new_active is not NULL, will send now the patches which I tested today.

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