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
| ||
|
Date: Mon, 11 Jun 2012 22:00:47 -0700 From: Jay Vosburgh <fubar@...ibm.com> To: Weiping Pan <wpan@...hat.com> cc: netdev@...r.kernel.org, nicolas.2p.debian@...il.com Subject: Re: [PATCH net V2] bonding:force to use primary slave Weiping Pan <wpan@...hat.com> wrote: >When we set primary slave with module parameters, bond will always use this >primary slave as active slave. > >But when we modify primary slave via sysfs, it will call >bond_should_change_active() and take into account primary_reselect. > >And I think we should use the new primary slave as the new active slave >regardless of the value of primary_reselect, since primary slave really should >have priority than other slaves. The whole point of primary_reselect is that the primary slave does not have priority unless it meets the reselect criteria, or it is being enslaved. >primary_reselect is introduced to handle the failure or recovery of primary >slave, but when we modify primary slave via sysfs, we want to give it higher >priority, and it may or may not be a failure or recovery slave. > >Thus the behavior is the same with module parameters and meets the >administrator's expectation. I still disagree with this patch. My comments regarding the prior version were intended to mean that we should document the current behavior, not change the behavior and document the new behavior. If an administrator wishes for the newly set primary to immediately become the active slave, they can either leave primary_reselect at its default setting or utilize the available mechanism to change the active slave. Applying this patch eliminates the ability to alter the primary slave setting without simultaneously changing the active slave. Further, the default value for primary_reselect already does this (change to the new primary immediately); this patch only affects the case that primary_reselect is set to a non-default value. In my mind, this reinforces that the current behavior is correct, and that the primary_reselect setting should apply to the newly selected primary (because the administrator has explicitly chosen that behavior). -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
Powered by blists - more mailing lists