`uaccess` tag by default for /dev/udmabuf about systemd

[jwrdegoede]

I actually had sending out an email to discuss doing this with the dma-buf maintainers on my TODO list. I have just send out that email:

https://lore.kernel.org/all/[email protected]/

So lets await the dam-buf maintainers reply and discuss this further in that email thread.

[poettering]

We can certainly do something like this, but only if the relevant kernel subsystem maintainers sign off on this, that this is a safe thing to do.

@jwrdegoede iirc you are involved in the libcamera work, or did i mix that up? Any chance you can comment on this? Or CC the people who could?

[jwrdegoede]

The upstream kernel list discussion has come to the conclusion that opening up DMA heaps is a bad idea. But opening up /dev/udmabuf like this should be acceptable.

I have posted a patch upstream for libcamera to try udmabuf of the DMA heaps are not available:

https://lists.libcamera.org/pipermail/libcamera-devel/2024-May/042085.html

I think we should change the title of this issue to "uaccess tag by default for /dev/udmabuf". @rmader can you update this.

And/or maybe we should just submit a pull-request with this change ?

[keszybz]

rules.d/70-uaccess.rules.in

[ndufresne]

So far, it seems like a bad idea until dmabuf allocated from heaps can be accounted and under user quotas. I've let floating the idea for libcamera softISP to enable memfd + udmabuf (Laurent said memfd out of libcamera is a no-go). (but then you need kernels that enable udmabuf in the first place)

[rmader]

I think we should change the title of this issue to "uaccess tag by default for /dev/udmabuf". @rmader can you update this.

Agreed, looks like it will be a while until the accounting issues around dma heaps will have been resolved - done.

And/or maybe we should just submit a pull-request with this change ?

Sounds good! Won't get to it at least in the next two weeks, so please go ahead or I'll pick it up later.

[jwrdegoede]

Sounds good! Won't get to it at least in the next two weeks, so please go ahead or I'll pick it up later.

Any idea/suggestion which existing systemd udev rules file we should add this to ?