On 03/07/2013 04:50 PM, Linda Walsh wrote:
>
> I am *not* seeing the bug in 3.8.2 with the 2nd patch applied (in
> addition to the first)...
So that means bond lock is the reason, nice, but this is really not a
good fix if we just unlock it...
The better way is to move the cycle wait logical out of the
bond_update_speed_duplex() IMO, I think we need the folk who work on
this driver to make the decision ;-)
Regards,
Michael Wang
>
>
> Michael Wang wrote:
>>
>>
>> And both bond_enslave() and bond_mii_monitor() are using
>> bond_update_speed_duplex()
>> with preempt disabled.
>>
>> Along with the changes in bond_enslave(), I think you also need this
>> (untested):
>>
>> diff --git a/drivers/net/bonding/bond_main.c
>> b/drivers/net/bonding/bond_main.c
>> index 11d01d6..9af143a 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -2373,7 +2373,9 @@ static void bond_miimon_commit(struct bonding *bond)
>> bond_set_backup_slave(slave);
>> }
>>
>> + read_unlock(&bond->lock);
>> bond_update_speed_duplex(slave);
>> + read_lock(&bond->lock);
>>
>> pr_info("%s: link status definitely up for interface
>> %s, %u Mbps %s duplex.\n",
>> bond->dev->name, slave->dev->name,
>>
>>
>> Regards,
>> Michael Wang
>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
