01:43 <mareko> anarsoul: yes

04:33 <anarsoul> mareko: thanks. Could you assign https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/689 to marge if it looks OK to you?

16:55 <robclark> danvet, ickle, hmm, how does (or does?) i915 deal with evicting a bo that has been dmabuf exported and mmap'd via the dmabuf fd.. I've tracked down corruption w/ msm related to accessing dmabuf mmap after bo has been unpinned since we only unmap_mapping_range(dev->anon_inode->i_mapping) but that doesn't shoot down the dmabuf mmap.. (took me a while to figure out, until I had the bright idea to add dmabuf mmap to igt test I'm

16:55 <robclark> working on.. and then insta-boom)

16:56 <danvet> robclark, if you wire through all the helpers then in theory you should be able to forward the dma-buf mmap in such a way that unmap_mapping_range hits it

16:56 <danvet> but you need to adjust both the file and offset and everything in the mmap fwding

16:57 <danvet> robclark, dma_buf_mmap_internal as example

16:57 <robclark> hmm, I am, I think, using all the helpers..

16:57 <danvet> hm no that's not the example

17:00 <robclark> oh, but i915 doesn't use the helpers..

17:02 <danvet> robclark, not sure you want to trust me, I'm not even finding the unmap_mapping_range in msm right now :-/

17:02 <robclark> hmm, is vma_set_file() that i915_gem_dmabuf_mmap() does the magic I'm missing?

17:02 <robclark> danvet: called indirectly via drm helper ;-)

17:02 <robclark> drm_vma_node_unmap()

17:03 <danvet> ah I always miss that it's in the header

17:03 <danvet> robclark, yup vma_set_file it is

17:03 <danvet> I forgot we made it a wrapper

17:04 <danvet> robclark, and I just noticed that the helpers don't have that anywhere :-(

17:04 <danvet> so I guess you need to fix that and then it should be all good

17:04 <robclark> yup, I think that's the bug

17:04 <robclark> will know in a few min

17:04 <danvet> I thought we had all that, but the epic confusion that tzimmermann tracked down was only about vm_pgoff adjustment

17:04 <robclark> I guess it doesn't help that there isn't a lot of overlap between drivers using helpers and drivers doing eviction ;-)

17:05 <danvet> well there's a patch set in flight to adjust that

17:05 <robclark> i915 moving to helpers?

17:06 <danvet> nah adding a shrinker to helpers

17:07 <danvet> robclark, drm_gem_prime_mmap <- I guess this one should grow the vma_set_file and then it should be ok

17:07 <danvet> but not sure

17:07 <robclark> yeah, that's what I've done

17:07 <danvet> robclark, pls cc tzimmermann, he's more on top of all the hilarious corner cases our multi-layer mmap forwarding has

17:07 <robclark> hmm, shrinker or just purge (latter is easier since you won't purge something dmabuf exported)

17:07 <robclark> k

17:08 <danvet> hm we could ditch the gem_prime_mmap callback outright, everyone uses drm_gem_prime_mmap :-)

17:09 <robclark> hmm, no.. that seems not quite enough: [ 186.200593] Unable to handle kernel paging request at virtual address dedededededededc

17:10 <danvet> looks like some poison

17:10 <robclark> yeah, it's my poison ;-)

17:10 <danvet> robclark, do you have a gem_bo->ops->mmap implementation?

17:10 <robclark> memset'ing the dmabuf mmap to 0xde

17:10 <robclark> yeah

17:11 <danvet> uh which file did you pick?

17:11 <robclark> ?

17:15 <robclark> hmm, ok, dmabuf export should be setting `dma_buf->file->f_mapping = obj->dev->anon_inode->i_mapping`..

17:15 <danvet> yeah

17:15 <danvet> for which we'd need a special file since you really don't have one

17:15 <danvet> i915 does that, except the justification is hilariously bad and wrong

17:16 <danvet> or something like that

17:16 <danvet> robclark, I think I'll go back into w/e

17:16 <robclark> I suppose that is more fun than mm

18:56 <robclark> oh, extra lolz, drm_vma_node_unmap() is a no-op if the drm_mm node is not allocated.. which it won't be if no one has asked for the drm_fd mmap offset.. and ofc unmap_mapping_range_tree() works in terms of vma->vm_start which ofc isn't going to match the drm_mm node.. I think I've found myself a rabbit hole..

20:11 <danvet> robclark, the vm_start we adjust already

20:12 <danvet> and the helper asks for the vma offset to make that adjustment

20:12 <danvet> I think at least, but maybe the illusion is not quite working

20:12 <robclark> no, vm_pgoff is what we adjust.. although that might be enough, I'm still wading thru it