On Fri, Oct 23, 2020 at 06:49:11PM +0200, Daniel Vetter wrote:
> > +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> > + unsigned long offset, size_t size,
> > + int fd, int access,
> > + const struct dma_buf_attach_ops *ops)
> > +{
> > + struct dma_buf *dmabuf;
> > + struct ib_umem_dmabuf *umem_dmabuf;
> > + struct ib_umem *umem;
> > + unsigned long end;
> > + long ret;
> > +
> > + if (check_add_overflow(offset, (unsigned long)size, &end))
> > + return ERR_PTR(-EINVAL);
> > +
> > + if (unlikely(PAGE_ALIGN(end) < PAGE_SIZE))
> > + return ERR_PTR(-EINVAL);
> > +
> > + if (unlikely(!ops || !ops->move_notify))
> > + return ERR_PTR(-EINVAL);
> > +
> > +#ifdef CONFIG_DMA_VIRT_OPS
> > + if (device->dma_device->dma_ops == &dma_virt_ops)
> > + return ERR_PTR(-EINVAL);
> > +#endif
>
> Maybe I'm confused, but should we have this check in dma_buf_attach, or at
> least in dma_buf_dynamic_attach? The p2pdma functions use that too, and I
> can't imagine how zerocopy should work (which is like the entire point of
> dma-buf) when we have dma_virt_ops.
The problem is we have RDMA drivers that assume SGL's have a valid
struct page, and these hacky/wrong P2P sgls that DMABUF creates cannot
be passed into those drivers.
But maybe this is just a 'drivers are using it wrong' if they call
this function and expect struct pages..
The check in the p2p stuff was done to avoid this too, but it was on a
different flow.
Jason
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
