On 07-Jan-19 19:08, Jason Gunthorpe wrote: > On Mon, Jan 07, 2019 at 04:24:58PM +0200, Gal Pressman wrote: >> 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. > > The mmap cookie is removed from the tracking structure after mmap - > how exactly does it prevent re-use with that design? The key itself is being increased on each allocation and is not reused, the BAR pages referred by the key are reused (which can be solved, discussion in other thread).
