Lubin, I am not sure if you are referring to your version of the driver or the mainline version! If I read the mainline version correctly, sas_deform_port() actually removes a phy from a port and also removes all attached devices if it is the last phy in the port. When a phy/port is gone, an event is posted to the work queue to eventually call sas_deform_port(). Let me know if I misunderstood the mainline version. Thanks, Malahal. Luben Tuikov [ltuikov@xxxxxxxxx] wrote: > --- malahal@xxxxxxxxxx wrote: > > sas_discover_domain() and sas_deform_port() assume that they are single > > threaded and never run in parallel. > > This is indeed not true. > > > That is mostly true as we have a > > single threaded work queue to handle discovery and other events. > > Hint: when the port is gone, it is gone... > > > The > > only race I find is unloading a module will call sas_deform_port() > > without watching if there is a discovery event is in progress. This > > patch will stop queuing further events, flush the queue, and then call > > sas_deform_port() to avoid the race. > > You need a much more elaborate (read: general solution, aka algorithm) > framework to solve this. > > Needless to say, I don't observe these bugs and errors in my version > of the SAS Stack. > > Luben > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
