[Intel-gfx] [PATCH] drm-buf: Add debug option

Chris Wilson chris at chris-wilson.co.uk
Wed Jan 13 21:08:54 UTC 2021


Quoting Daniel Vetter (2021-01-13 20:50:11)
> On Wed, Jan 13, 2021 at 4:43 PM Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >
> > Quoting Daniel Vetter (2021-01-13 14:06:04)
> > > We have too many people abusing the struct page they can get at but
> > > really shouldn't in importers. Aside from that the backing page might
> > > simply not exist (for dynamic p2p mappings) looking at it and using it
> > > e.g. for mmap can also wreak the page handling of the exporter
> > > completely. Importers really must go through the proper interface like
> > > dma_buf_mmap for everything.
> >
> > If the exporter doesn't want to expose the struct page, why are they
> > setting it in the exported sg_table?
> 
> You need to store it somewhere, otherwise the dma-api doesn't work.
> Essentially this achieves clearing/resetting the struct page pointer,
> without additional allocations somewhere, or tons of driver changes
> (since presumably the driver does keep track of the struct page
> somewhere too).

Only for mapping, and that's before the export -- if there's even a
struct page to begin with.
 
> Also as long as we have random importers looking at struct page we
> can't just remove it, or crashes everywhere. So it has to be some
> debug option you can disable.

Totally agreed that nothing generic can rely on pages being transported
via dma-buf, and memfd is there if you do want a suitable transport. The
one I don't know about is dma-buf heap, do both parties there consent to
transport pages via the dma-buf? i.e. do they have special cases for
import/export between heaps?
-Chris


More information about the dri-devel mailing list