On Tue, Aug 13, 2019 at 03:00:22PM -0300, Jason Gunthorpe wrote: > 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. I misspoke. I should have said associated with this "context". And of course uverbs_destroy_ufile_hw() does not touch the FD. What I mean is that the struct file which had file_pins hanging off of it would be getting its file pins destroyed by uverbs_destroy_ufile_hw(). Therefore we don't need the FD after uverbs_destroy_ufile_hw() is done. But since it does not block it may be that the struct file is gone before the MR is actually destroyed. Which means I think the GUP code would blow up in that case... :-( I was thinking it was the other way around. And in fact most of the time I think it is. But we can't depend on that... > > > > 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 What is "It"? The struct file? Or the file pin information? > handle the file is guarenteed to exist, and we've now arranged things I don't understand what you mean by "... once you are in file operations handle... "? > so the uattr_bundle flows into the umem, as umems can only be > established under a system call. "uattr_bundle" == uverbs_attr_bundle right? The problem is that I don't think the core should be handling uverbs_attr_bundles directly. So, I think you are driving at the same idea I had WRT callbacks into the driver. The drivers could provide some generic object (in RDMA this could be the uverbs_attr_bundle) which represents their "context". The GUP code calls back into the driver with file pin information as it encounters and pins pages. The driver, RDMA in this case, associates this information with the "context". But for the procfs interface, that context then needs to be associated with any file which points to it... For RDMA, or any other "FD based pin mechanism", it would be up to the driver to "install" a procfs handler into any struct file which _may_ point to this context. (before _or_ after memory pins). Then the procfs code can walk the FD array and if this handler is installed it knows there is file pin information associated with that struct file and it can be printed... This is not impossible. But I think is a lot harder for drivers to make right... Ira
