On Wed, Apr 17, 2019 at 09:35:45PM +0000, Ruhl, Michael J wrote: > >So if you have AH's in use by another thread it must sleep during > >destroy.. > > What must sleep, the other thread or the destroy? The destroy.. > >> I am going to work up a patch to implement the SLEEPABLE path in our destroy > >> to deal with this. > > > >I thought that was only for create? Did we get an expectation that > >destroy is non-sleeping? I hope not.. > > Umm. The _destroy() interface has a destroy_flags parameter. Bleck, this AH thing is miserable. I wonder how many bugs we have here.. Well, you are stuck then, you have to make some kref based approach. The general direction here is for the core code to provide a kref for each object, so maybe we need to accelerate that for AH. > My assumption for this is that if RDMA_DESTROY_AH_SLEEPABLE is set, > the drivers _destroy() function must wait (sleep?) until all access (our internal refcount) > to the AH is compete. Not really, it is a foolish flag that we shouldn't have introduced :( At best it just means the caller is in an atomic context - but if your destroy requires sleep you can't just fail the destroy, so you pretty much are screwed and can't make a sleeping destroy anyhow. EFA is using this because they further assume that if the create is done sleepable then the destroy is always also sleepable and thus they cant alway sleep as they fail atomic create. Jason
