SAS illegal toplogies [was Re: [PATCH 1/4 v2] libsas: Don't BUG when connecting two expanders via wide port]

[Douglas Gilbert <dougg@torque.net>]

Darrick J. Wong wrote:
> libsas: Don't BUG when connecting two expanders via wide port
> 
> When a device is connected to an expander, the discovery process goes through
> sas_ex_discover_dev to figure out what's attached to the phy.  If it is the
> case that the phy being discovered happens to be the second phy of a wide link
> to an expander, that discover_dev function will incorrectly call
> sas_ex_discover_expander, which creates another sas_port and tries to attach the
> other sas_phys to the new port, thus triggering a BUG.  The correct thing to do is
> to check the other ex_phys of the expander to see if there's a sas_port for this
> sas_phy, and attach the sas_phy to the existing sas_port.
> 
> This is easily triggered if one enables the phys of a wide port between
> expanders one by one.
> 
> This second version of the patch fixes a small regression in the case where
> all the phys show up at once and we accidentally try to attach to a port
> that hasn't been created yet.

Darrick,
Okay.

Now I'm wondering what the discovery algorithm in libsas
does if it finds truly illegal connections between expanders.
The spec defines what is illegal but says it is vendor specific
what will be done.

One approach is to use the SMP PHY CONTROL function to disable
the phy (or the phys at both ends of the illegal link). The
next trick is how to tell the user who just connected a cable
between expanders that "you can't do that!". Tools like my
smp_discover could alert a user to a disabled phy but
without turning it back on (and causing the libsas discovery
algorithm another headache) my SMP utilities don't know what
it is connected to.

Another question is which link to disable. Imagine three
expanders interconnected with 3 links which is illegal.
Breaking any one link makes it legal, but which one
to break? Last seen, or perhaps the link which has
the largest SAS address sum ...

Doug Gilbert