08:52 <mwalle> lynxeye: btw, I don't get any smmu faults anymore. Thanks!

08:53 <mwalle> now I'm digging into that EEXISTS DMA mapping error

08:53 <lynxeye> mwalle: \o/

08:53 <mwalle> so feel free to add my tested-by

09:04 <mwalle> lynxeye: hm, I'm just testing the patches one by one and 6/8 seems to cause a kernel oops (which is then fixed by a later patch), let me double check and I'll come back to you

09:06 <lynxeye> mwalle: I'll take a second look before sending them out properly. The series was quite a quick shot to allow you to test if my theories hold. ;)

09:10 <mwalle> lynxeye: sure, if it helps, here is the oops which happens if only patches 1 through 6 are applied: https://pastebin.com/raw/t1tLRzad

09:10 <mwalle> lynxeye: which is gone after applying patch 7

09:11 <lynxeye> mwalle: Thanks, that's helpful. I'll investigate this later today.

09:51 <austriancoder> lynxeye: hey I haven't seen a kernel PR yet (there is some stuff in etnaviv/next)

10:06 <lynxeye> austriancoder: Yep, I'm on it. But thanks for the reminder. :)

10:49 <lynxeye> mwalle: He, yea the code changes now turn the implicit use-after-free from the GPU (what your IOMMU caught) into a explicit use-after-free from the CPU, crashing the kernel. I need to reorder the changes to avoid that happening in the middle of the series.

11:01 <mwalle> lynxeye: i've put a WARN_ON(1) before the EEXIST warning. https://pastebin.com/raw/j8trrw5m Does this already tell you if this is likely a bug in mesa/drm or in the driver?

11:11 <lynxeye> mwalle: Hm, at least without a compositor we shouldn't see duplicated imports of dma-bufs, as this is a real coherence issue. I wonder why I'm not seeing this warning.

11:54 <mwalle> lynxeye: i don't use a particular mesa version though, just some version from 20th of july with your MR patches.