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]
Date:	Mon, 11 Jun 2012 14:17:21 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	=?UTF-8?B?Tmljb2xhcyBkZSBQZXNsb8O8YW4=?= 
	<nicolas.2p.debian@...il.com>
cc:	Weiping Pan <wpan@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net 3/3] bonding:force to use primary slave

Nicolas de Pesloüan 	<nicolas.2p.debian@...il.com> wrote:

>Le 11/06/2012 11:00, Weiping Pan a écrit :
>> 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.
>> Thus the behavior is the same with module parameters and meets the
>> administrator's expectation.
>>
>> Signed-off-by: Weiping Pan<wpan@...hat.com>
>> ---
>>   drivers/net/bonding/bond_sysfs.c |    1 +
>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
>> index 1b0f3cd..7256ae4 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -1077,6 +1077,7 @@ static ssize_t bonding_store_primary(struct device *d,
>>   				bond->dev->name, slave->dev->name);
>>   			bond->primary_slave = slave;
>>   			strcpy(bond->params.primary, slave->dev->name);
>> +			bond->force_primary = true;
>>   			bond_select_active_slave(bond);
>>   			goto out;
>>   		}
>
>Not sure this is the right behavior. One may want to change the primary
>without causing a switch to this primary if another slave is already
>active, and setup primary_reselect to failure or better for that
>reason. The administrator still have the option to write into
>active_slave, to force the new active slave after changing the primary.
>
>Arguably, this should be documented.

	I suspect it is obeying the documented behavior, at least for
the behaviors that are documented.

	The documentation already says that "When initially enslaved,
the primary slave is always made the active slave."  That's probably
what covers the "module param" case, because the options are all set
prior to any slaves being added, so when the primary slave is later
enslaved, it is made the active slave immediately.

	Now, the documentation for the primary option itself also says:

	"The specified device will always be the active slave while it
	is available.  Only when the primary is off-line will alternate
	devices be used."

	Which is the old behavior, prior to primary_reselect being added
(although it is still the default behavior).  This should probably
change to reflect the actual behavior, i.e., that changing the primary
option in real time results in a reselection of the primary according to
the policy specified by primary_reselect.

	-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ