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? Jason
