kernel/git/next/linux-next.git/drivers/dma-buf, branch master

Merge drm/drm-next into drm-misc-next

2026-09-07T11:44:24+00:00

Backmerging to get drm-misc-next up to v7.3-rc2. Requested for commit 3a2c4d55e32a ("treewide: refresh kmalloc_obj() conversions"). Signed-off-by: Thomas Zimmermann

Merge tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2026-09-06T03:45:18+00:00

Pull kmalloc_obj conversions from Kees Cook: "Another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci" * tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: refresh kmalloc_obj() conversions drm/amd/display: Fix harmless type mismatch in allocation

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

dma-buf: fix comment in dma_buf_llseek to match implementation

2026-09-02T08:04:55+00:00

The comment in dma_buf_llseek() referenced a "SEEK_END(0), SEEK_CUR(0) pattern", but the implementation does not support SEEK_CUR - it only handles SEEK_END and SEEK_SET, returning -EINVAL for anything else. Replace SEEK_CUR with SEEK_SET in the comment so that it accurately describes the supported idiomatic pattern. Signed-off-by: Haojie Li Link: https://lore.kernel.org/r/20260825064041.328640-1-lihaojie@kylinos.cn Reviewed-by: Christian König Signed-off-by: Christian König

Merge drm/drm-fixes into drm-misc-fixes

2026-09-01T07:38:51+00:00

Let's start the 7.3 drm-misc-fixes cycle. Signed-off-by: Maxime Ripard

Merge drm/drm-next into drm-misc-next

2026-08-31T07:01:06+00:00

Getting drm-misc-next up to v7.3-rc1. In exynos, there was a conflict in exynos_dbi_bind(). The merge resolves it to the state of commit 3cc8eee9f346 ("drm/exynos: remove dependency on DRM simple helpers"). Signed-off-by: Thomas Zimmermann

dma-buf: fix coding style in dma_resv_get_singleton

2026-08-25T07:18:31+00:00

The conditional "if (r)" following the dma_resv_get_fences() call was indented with spaces instead of a tab, violating the kernel coding style. Fix it to use a single tab for consistency with the rest of the function. Signed-off-by: Haojie Li Link: https://lore.kernel.org/r/20260825064815.331653-1-lihaojie@kylinos.cn Reviewed-by: Christian König Signed-off-by: Christian König

dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds

2026-08-24T11:57:59+00:00

DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework") Cc: stable@vger.kernel.org Reviewed-by: T.J. Mercier Acked-by: Christian König Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-2-shoubaineng@gmail.com Signed-off-by: Christian König

BackMerge tag 'v7.2' into drm-next

2026-08-20T00:58:44+00:00

Linux 7.2 There was a lot of conflicts this round between fixes and next, and I'd like to get the merge resolutions that we have in drm-tip. Signed-off-by: Dave Airlie

dma-buf/udmabuf: Disable the size limit by default

2026-08-04T05:48:11+00:00

As udmabuf increasingly enjoys popularity - being used in projects like libcamera, Gstreamer, Mesa, KWin and Weston - 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 and high bit depths. In its current form the size limit for individual buffers does not seem to provide any additional level of protection - such as limiting the amount of memory a process can pin - as the later can just allocate multiple buffers. If additional guardrails are desired, they would likely require some kind accounting not limited to individual buffers. Therefor let's disable the size limit by default by setting it to the maximal possible value, INT_MAX. Signed-off-by: Robert Mader Acked-by: Vivek Kasireddy Link: https://lore.kernel.org/dri-devel/20260711144814.8205-1-robert.mader@collabora.com/ Link: https://lore.kernel.org/dri-devel/6764ca6f-b4d8-4baa-9d27-2ca867ac2d41@amd.com/ Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260722110145.36641-1-robert.mader@collabora.com