On Thu, May 28, 2020 at 03:44:37PM -0400, Douglas Gilbert wrote: > > And then maybe you could make a convincing argument that the spin_lock > > there could be turned into an xa_lock since that will prevent sdevs from > > coming & going during the iteration of the device list. > > I tried that but ran into problems. The xarray model is clear enough, > but there is a (non-atomic) enumerated state in each sdev (struct > scsi_device object (pointer)) that is protected by a mutex. > I was unable to escape those pesky (but very useful) warnings out of > the depths of xarray that the locking was awry. When I've burrowed > into xarray.c I have usually found that it was correct. So now I regard > it as a pesky feature :-) Fascinating. So much of SCSI has to be IRQ-safe, and yet you can't look at the sdev state outside process context ... > > This patch seems decent enough ... I just think the decision to optimise > > the layout for LUNs < 256 is a bit odd. But hey, your subsystem, > > not mine. > > Hannes has the most experience in that area. He has only been using xarray > for a week or so (I think). There is something important missing from his > patchset: any xa_destroy() calls :-) They're not necessarily needed. If the XArray is empty, there's nothing to do.
