> -----Original Message----- > From: Daniel Vetter <[email protected]> > Sent: Tuesday, November 10, 2020 6:44 AM > To: Jason Gunthorpe <[email protected]> > Cc: Daniel Vetter <[email protected]>; Xiong, Jianxin > <[email protected]>; Leon Romanovsky <[email protected]>; linux- > [email protected]; [email protected]; Doug Ledford > <[email protected]>; Vetter, Daniel <[email protected]>; > Christian Koenig <[email protected]> > Subject: Re: [PATCH v8 1/5] RDMA/umem: Support importing dma-buf as user > memory region > > On Tue, Nov 10, 2020 at 10:27:57AM -0400, Jason Gunthorpe wrote: > > On Tue, Nov 10, 2020 at 03:14:45PM +0100, Daniel Vetter wrote: > > > On Fri, Nov 06, 2020 at 12:39:53PM -0400, Jason Gunthorpe wrote: > > > > On Fri, Nov 06, 2020 at 04:34:07PM +0000, Xiong, Jianxin wrote: > > > > > > > > > > The user could specify a length that is beyond the dma buf, > > > > > > can the dma buf length be checked during get? > > > > > > > > > > In order to check the length, the buffer needs to be mapped. That can > > > > > be done. > > > > > > > > Do DMA bufs even have definitate immutable lengths? Going to be a > > > > probelm if they can shrink > > > > > > Yup. Unfortunately that's not document in the structures themselves, > > > there's just some random comments sprinkled all over that dma-buf > > > size is invariant, e.g. see the @mmap kerneldoc in dma_buf_ops: > > > > > > https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlig > > > ht=dma_buf_ops#c.dma_buf_ops > > > > > > "Because dma-buf buffers have invariant size over their lifetime, ..." > > > > > > Jianxin, can you pls do a kerneldoc patch which updates the comment > > > for dma_buf.size and dma_buf_export_info.size?
Sure. > > > > So we can check the size without doing an attachment? > > Yeah size should be invariant over the lifetime of the dma_buf (it's also > needed for dma_buf_vmap kernel cpu access and dma_buf_mmap > userspace mmap forwarding). No lock or attachment needed. But like I said, > would be good to have the kerneldoc patch to make this clear. > > The history here is that the X shm extension suffered badly from resizeable > storage object exploits of the X server, this is why both dma-buf > (and also drm_gem_buffer_object before that generalization) and memfd are > size sealed. > -Daniel > > > That means the flow should be put back to how it was a series or two > > ago where the SGL is only attached during page fault with the entire > > programming sequence under the resv lock Will do. > > > > Jason > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
