On Thursday, March 2nd, 2023 at 14:45, Christian König <christian.koenig@xxxxxxx> wrote: > Am 02.03.23 um 14:37 schrieb Simon Ser: > > > On Thursday, March 2nd, 2023 at 14:21, Christian König christian.koenig@xxxxxxx wrote: > > > > > Am 02.03.23 um 11:14 schrieb Simon Ser: > > > > > > > On Thursday, March 2nd, 2023 at 08:11, Christian König christian.koenig@xxxxxxx wrote: > > > > > > > > > Am 01.03.23 um 23:29 schrieb Simon Ser: > > > > > > > > > > > We don't populate gem_prime_import_sg_table so only DMA-BUFs > > > > > > exported from our own device can be imported. Still, this is useful > > > > > > to user-space. > > > > > > But what happens if one of your BOs is imported into another device? > > > > > > Is there a way to make this fail, always? > > > > > > Well you could return an error from the attach callback if I'm not > > > > > > completely mistaken. > > > > > > Hmm, but with GEM helpers this is handled by drm_gem_map_attach(). That > > > > > > function calls drm_gem_object_funcs.pin but doesn't pass along the > > > > > > dma_buf_attachment so there no way to reject the attach based on the > > > > > > other device there… > > > > Would it be unreasonable to add a drm_driver.gem_prime_attach hook? Or > > is there a better way to implement this? > > That would be the mid layering we usually try hard to avoid. Indeed! > Your obj doesn't implement the obj->funcs->get_sg_table() callback > doesn't it? In this case drm_gem_map_dma_buf() would fail just a little > bit later anyway. > > What you could do is to add a check for the get_sg_table callback a bit > earlier in drm_gem_map_attach() and if that's not implemented reject the > attachment. That's a good idea, thanks for the suggestion! Done in v2.
