On Tue, 2014-03-18 at 18:10 -0700, Luis R. Rodriguez wrote:

On Tue, Mar 18, 2014 at 6:04 PM, Toshiaki Makita
[off-list ref] wrote:

quoted

(2014/03/19 9:50), Luis R. Rodriguez wrote:

quoted

On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
[off-list ref] wrote:

quoted

nit,
If the last detached port happens to have the same addr as
random_init_addr, this seems to call br_stp_change_bridge_id() even
though bridge_id is not changed.

Ah good point.

quoted

Shouldn't the assignment of random_init_addr be done before the check of
"no change"?

Good question, should we even allow two ports to have the same MAC
address or should we complain and refuse to add it? If so that should
mean we should also have to monitor any manual address changes or
events for address changes on the ports.

This was recently discussed by Stephen and me.
I'm thinking it should be allowed.

http://marc.info/?l=linux-netdev&m=139182743919257&w=2

Great now that that's sorted out though I still think calling
br_stp_change_bridge_id() is right just as calling the update features
as the device is different. It could however be confusing when this
situation is run and folks might report odd bugs unless we could tell
them apart clearly. Thoughts?

br_stp_change_bridge_id() is currently called only if bridge_id.addr
should be changed.
If the addr should not be changed but some updates are needed,
br_stp_recalculate_bridge_id() doesn't seem to fit into it.

Toshiaki Makita