On 06-Jan-19 23:33, Jason Gunthorpe wrote: > On Sun, Jan 06, 2019 at 11:40:39AM +0200, Gal Pressman wrote: > >>> And this whole mmap_entries data structure looks like a big confusing >>> mess to me, I think it should just be trivial usage of xarray if I >>> understand what it is trying to do. (and doing remove during mmap >>> seems really wrong to me, mmap cookies should exist as long as the >>> owning object exists..) >> >> The motivation here is that the user calls create_qp/cq, the driver allocates >> the DMA buffers and returns an mmap key. >> The user should use the same key to mmap the buffers that the driver allocated >> for the qp/cq. >> The mmap_entries are a way to identify mmap_key to DMA buffers, objects are >> added to the list on creation and removed on mmap call (when the queues are >> mapped and the key -> object translation is no longer needed). > > This is a nonsense way to run the system call interface. Any mmap > cookies should not be re-used so long as the FD exists, and there is > not really a good reason to deny user space a second go at mmap on > things like bar pages since the bar page must remain assigned until > the ucontext is destroyed. See the other thread. > > Deviating from the usual practice is just going to create bugs. By mmap cookies you're referring to the mmap_key? we don't reuse those. What is the usual practice? IIRC, we use the same practice as cxgb4.
