Hi Vivek,
On 14.07.26 08:42, Kasireddy, Vivek wrote:
Hi Robert,
Subject: Re: [RFC PATCH 1/2] dma-buf/udmabuf: Introduce
CONFIG_UDMABUF_SIZE_LIMIT_MBYTES
Hi,
On 13.07.26 11:12, Christian König wrote:
On 7/11/26 16:48, Robert Mader wrote:
As udmabuf increasingly enjoys popularity - being used in projects
like
libcamera, Gstreamer, Mesa and KWin - users more frequently
encounter
cases where the current default size limit of 64MB is too low.
Examples
include allocating video buffers at a 8K resolution - and even 4K is
affected when using non-subsampled video formats or high bit
depths.
While the limit can already be changed via the kernel command line,
exposing it as a kernel config makes that easier and more
discoverable
for distros. Thus let's do that.
Well config options are usually only useful if the value can't be
changed on runtime through a module parameter, but that is clearly
not the case here.
On the other hand I do see your problem. I would just vote to disable
the limit by default, there is nothing preventing userspace from
allocating multiple uDMA-bufs so it doesn't seem to prevent any
security issue or similar.
I fully agree and would prefer that as well. If there is no resistance /
concerns from anybody I'll send a corresponding patch at the end of the
week.
AFAIU, the main motivation behind the limits was to ensure that there are
some kind of guardrails. I am not opposed to their removal but I think it
would now allow users to pin large arbitrary amounts of memory and I
feel like there needs to be a way to prevent users from doing that.
Early RFC versions of udmabuf had mlock accounting to address this issue
but not sure why it was dropped eventually. I am wondering if it makes
sense to bring that back.
while the point about pinned memory accounting sounds reasonable to me,
I don't think that removing the limit for individual uDMA-bufs would
change anything about the current situation. As Christian already
pointed out there's nothing preventing clients to allocate multiple
uDMA-bufs atm. In fact I believe that the scenario you describe
currently is more likely to be caused by clients allocating (and e.g.
leaking) many small uDMA-bufs.
There are, however, some other existing guardrails that may somewhat
help already:
1. systemd limits udmabuf access to uaccess - i.e. local seats /
graphical users (https://github.com/systemd/systemd/pull/33738)
2. at least the Flatpak sandbox binds udmabuf access to DRI device
access as the later is considered "more powerful"
(https://github.com/flatpak/flatpak/pull/6158)
I'll therefor go forward and a propose a patch to remove the individual
limit, assuming the discussion about mlock (or some kind of more global)
accounting can be continued independently.
Thanks,
Robert
Thanks,
Vivek
Thanks,
Robert
Regards,
Christian.
Signed-off-by: Robert Mader<[email protected]>
---
drivers/dma-buf/Kconfig | 6 ++++++
drivers/dma-buf/udmabuf.c | 4 ++++
2 files changed, 10 insertions(+)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 7efc0f0d0712..35f0779cdc80 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -40,6 +40,12 @@ config UDMABUF
A driver to let userspace turn memfd regions into dma-bufs.
Qemu can use this to create host dmabufs for guest
framebuffers.
+config UDMABUF_SIZE_LIMIT_MBYTES
+ int "Size limit in Mega Bytes"
+ default 64
+ help
+ Maximum size of a udmabuf, in megabytes. Default is 64.
+
config DMABUF_DEBUG
bool "DMA-BUF debug checks"
depends on DMA_SHARED_BUFFER
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index bced421c0d65..a83153326362 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -20,7 +20,11 @@ static int list_limit = 1024;
module_param(list_limit, int, 0644);
MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit.
Default is 1024.");
+#ifdef CONFIG_UDMABUF_SIZE_LIMIT_MBYTES
+static int size_limit_mb = CONFIG_UDMABUF_SIZE_LIMIT_MBYTES;
+#else
static int size_limit_mb = 64;
+#endif
module_param(size_limit_mb, int, 0644);
MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in
megabytes. Default is 64.");
--
2.55.0
--
Robert Mader
Consultant Software Developer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
