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

[Or Gerlitz <ogerlitz@voltaire.com>]

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.