On Tue, Aug 13, 2019 at 10:41:42AM -0700, Ira Weiny wrote: > And I was pretty sure uverbs_destroy_ufile_hw() would take care of (or ensure > that some other thread is) destroying all the MR's we have associated with > this > FD.
fd's can't be revoked, so destroy_ufile_hw() can't touch them. It deletes any underlying HW resources, but the FD persists. > > This is why having a back pointer like this is so ugly, it creates a > > reference counting cycle > > Yep... I worked through this... and it was giving me fits... > > Anyway, the struct file is the only object in the core which was reasonable to > store this information in since that is what is passed around to other > processes... It could be passed down in the uattr_bundle, once you are in file operations handle the file is guarenteed to exist, and we've now arranged things so the uattr_bundle flows into the umem, as umems can only be established under a system call. Jason
