Linaro-mm-sig January 2026

linaro-mm-sig@lists.linaro.org

44 participants
36 discussions

[PATCH] dma-buf: Remove DMA-BUF sysfs stats

by T.J. Mercier

Commit bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") added dmabuf statistics to sysfs in 2021 under CONFIG_DMABUF_SYSFS_STATS. After being used in production, performance problems were discovered leading to its deprecation in 2022 in commit e0a9f1fe206a ("dma-buf: deprecate DMABUF_SYSFS_STATS"). Some of the problems with this interface were discussed in my LPC 2025 talk. [1][2] Android was probably the last user of the interface, which has since been migrated to use the dmabuf BPF iterator [3] to obtain the same information more cheaply. As promised in that series, now that the longterm stable 6.18 kernel has been released let's remove the sysfs dmabuf statistics from the kernel. [1] https://www.youtube.com/watch?v=D83qygudq9c [2] https://lpc.events/event/19/contributions/2118/ [3] https://lore.kernel.org/all/20250522230429.941193-1-tjmercier@google.com/ Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- .../ABI/testing/sysfs-kernel-dmabuf-buffers | 24 --- Documentation/driver-api/dma-buf.rst | 5 - drivers/dma-buf/Kconfig | 15 -- drivers/dma-buf/Makefile | 1 - drivers/dma-buf/dma-buf-sysfs-stats.c | 202 ------------------ drivers/dma-buf/dma-buf-sysfs-stats.h | 35 --- drivers/dma-buf/dma-buf.c | 18 -- include/linux/dma-buf.h | 12 -- 8 files changed, 312 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers delete mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c delete mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers deleted file mode 100644 index 5d3bc997dc64..000000000000 --- a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers +++ /dev/null @@ -1,24 +0,0 @@ -What: /sys/kernel/dmabuf/buffers -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju <hridya(a)google.com> -Description: The /sys/kernel/dmabuf/buffers directory contains a - snapshot of the internal state of every DMA-BUF. - /sys/kernel/dmabuf/buffers/<inode_number> will contain the - statistics for the DMA-BUF with the unique inode number - <inode_number> -Users: kernel memory tuning/debugging tools - -What: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju <hridya(a)google.com> -Description: This file is read-only and contains the name of the exporter of - the DMA-BUF. - -What: /sys/kernel/dmabuf/buffers/<inode_number>/size -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju <hridya(a)google.com> -Description: This file is read-only and specifies the size of the DMA-BUF in - bytes. diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 29abf1eebf9f..2f36c21d9948 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -125,11 +125,6 @@ Implicit Fence Poll Support .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: implicit fence polling -DMA-BUF statistics -~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/dma-buf/dma-buf-sysfs-stats.c - :doc: overview - DMA Buffer ioctls ~~~~~~~~~~~~~~~~~ diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index fdd823e446cc..012d22e941d6 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -75,21 +75,6 @@ menuconfig DMABUF_HEAPS allows userspace to allocate dma-bufs that can be shared between drivers. -menuconfig DMABUF_SYSFS_STATS - bool "DMA-BUF sysfs statistics (DEPRECATED)" - depends on DMA_SHARED_BUFFER - help - Choose this option to enable DMA-BUF sysfs statistics - in location /sys/kernel/dmabuf/buffers. - - /sys/kernel/dmabuf/buffers/<inode_number> will contain - statistics for the DMA-BUF with the unique inode number - <inode_number>. - - This option is deprecated and should sooner or later be removed. - Android is the only user of this and it turned out that this resulted - in quite some performance problems. - source "drivers/dma-buf/heaps/Kconfig" endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 2008fb7481b3..7a85565d906b 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -6,7 +6,6 @@ obj-$(CONFIG_DMABUF_HEAPS) += heaps/ obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o -obj-$(CONFIG_DMABUF_SYSFS_STATS) += dma-buf-sysfs-stats.o dmabuf_selftests-y := \ selftest.o \ diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c deleted file mode 100644 index b5b62e40ccc1..000000000000 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ /dev/null @@ -1,202 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/* - * DMA-BUF sysfs statistics. - * - * Copyright (C) 2021 Google LLC. - */ - -#include <linux/dma-buf.h> -#include <linux/dma-resv.h> -#include <linux/kobject.h> -#include <linux/printk.h> -#include <linux/slab.h> -#include <linux/sysfs.h> - -#include "dma-buf-sysfs-stats.h" - -#define to_dma_buf_entry_from_kobj(x) container_of(x, struct dma_buf_sysfs_entry, kobj) - -/** - * DOC: overview - * - * ``/sys/kernel/debug/dma_buf/bufinfo`` provides an overview of every DMA-BUF - * in the system. However, since debugfs is not safe to be mounted in - * production, procfs and sysfs can be used to gather DMA-BUF statistics on - * production systems. - * - * The ``/proc/<pid>/fdinfo/<fd>`` files in procfs can be used to gather - * information about DMA-BUF fds. Detailed documentation about the interface - * is present in Documentation/filesystems/proc.rst. - * - * Unfortunately, the existing procfs interfaces can only provide information - * about the DMA-BUFs for which processes hold fds or have the buffers mmapped - * into their address space. This necessitated the creation of the DMA-BUF sysfs - * statistics interface to provide per-buffer information on production systems. - * - * The interface at ``/sys/kernel/dmabuf/buffers`` exposes information about - * every DMA-BUF when ``CONFIG_DMABUF_SYSFS_STATS`` is enabled. - * - * The following stats are exposed by the interface: - * - * * ``/sys/kernel/dmabuf/buffers/<inode_number>/exporter_name`` - * * ``/sys/kernel/dmabuf/buffers/<inode_number>/size`` - * - * The information in the interface can also be used to derive per-exporter - * statistics. The data from the interface can be gathered on error conditions - * or other important events to provide a snapshot of DMA-BUF usage. - * It can also be collected periodically by telemetry to monitor various metrics. - * - * Detailed documentation about the interface is present in - * Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers. - */ - -struct dma_buf_stats_attribute { - struct attribute attr; - ssize_t (*show)(struct dma_buf *dmabuf, - struct dma_buf_stats_attribute *attr, char *buf); -}; -#define to_dma_buf_stats_attr(x) container_of(x, struct dma_buf_stats_attribute, attr) - -static ssize_t dma_buf_stats_attribute_show(struct kobject *kobj, - struct attribute *attr, - char *buf) -{ - struct dma_buf_stats_attribute *attribute; - struct dma_buf_sysfs_entry *sysfs_entry; - struct dma_buf *dmabuf; - - attribute = to_dma_buf_stats_attr(attr); - sysfs_entry = to_dma_buf_entry_from_kobj(kobj); - dmabuf = sysfs_entry->dmabuf; - - if (!dmabuf || !attribute->show) - return -EIO; - - return attribute->show(dmabuf, attribute, buf); -} - -static const struct sysfs_ops dma_buf_stats_sysfs_ops = { - .show = dma_buf_stats_attribute_show, -}; - -static ssize_t exporter_name_show(struct dma_buf *dmabuf, - struct dma_buf_stats_attribute *attr, - char *buf) -{ - return sysfs_emit(buf, "%s\n", dmabuf->exp_name); -} - -static ssize_t size_show(struct dma_buf *dmabuf, - struct dma_buf_stats_attribute *attr, - char *buf) -{ - return sysfs_emit(buf, "%zu\n", dmabuf->size); -} - -static struct dma_buf_stats_attribute exporter_name_attribute = - __ATTR_RO(exporter_name); -static struct dma_buf_stats_attribute size_attribute = __ATTR_RO(size); - -static struct attribute *dma_buf_stats_default_attrs[] = { - &exporter_name_attribute.attr, - &size_attribute.attr, - NULL, -}; -ATTRIBUTE_GROUPS(dma_buf_stats_default); - -static void dma_buf_sysfs_release(struct kobject *kobj) -{ - struct dma_buf_sysfs_entry *sysfs_entry; - - sysfs_entry = to_dma_buf_entry_from_kobj(kobj); - kfree(sysfs_entry); -} - -static const struct kobj_type dma_buf_ktype = { - .sysfs_ops = &dma_buf_stats_sysfs_ops, - .release = dma_buf_sysfs_release, - .default_groups = dma_buf_stats_default_groups, -}; - -void dma_buf_stats_teardown(struct dma_buf *dmabuf) -{ - struct dma_buf_sysfs_entry *sysfs_entry; - - sysfs_entry = dmabuf->sysfs_entry; - if (!sysfs_entry) - return; - - kobject_del(&sysfs_entry->kobj); - kobject_put(&sysfs_entry->kobj); -} - - -/* Statistics files do not need to send uevents. */ -static int dmabuf_sysfs_uevent_filter(const struct kobject *kobj) -{ - return 0; -} - -static const struct kset_uevent_ops dmabuf_sysfs_no_uevent_ops = { - .filter = dmabuf_sysfs_uevent_filter, -}; - -static struct kset *dma_buf_stats_kset; -static struct kset *dma_buf_per_buffer_stats_kset; -int dma_buf_init_sysfs_statistics(void) -{ - dma_buf_stats_kset = kset_create_and_add("dmabuf", - &dmabuf_sysfs_no_uevent_ops, - kernel_kobj); - if (!dma_buf_stats_kset) - return -ENOMEM; - - dma_buf_per_buffer_stats_kset = kset_create_and_add("buffers", - &dmabuf_sysfs_no_uevent_ops, - &dma_buf_stats_kset->kobj); - if (!dma_buf_per_buffer_stats_kset) { - kset_unregister(dma_buf_stats_kset); - return -ENOMEM; - } - - return 0; -} - -void dma_buf_uninit_sysfs_statistics(void) -{ - kset_unregister(dma_buf_per_buffer_stats_kset); - kset_unregister(dma_buf_stats_kset); -} - -int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file) -{ - struct dma_buf_sysfs_entry *sysfs_entry; - int ret; - - if (!dmabuf->exp_name) { - pr_err("exporter name must not be empty if stats needed\n"); - return -EINVAL; - } - - sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); - if (!sysfs_entry) - return -ENOMEM; - - sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; - sysfs_entry->dmabuf = dmabuf; - - dmabuf->sysfs_entry = sysfs_entry; - - /* create the directory for buffer stats */ - ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, - "%lu", file_inode(file)->i_ino); - if (ret) - goto err_sysfs_dmabuf; - - return 0; - -err_sysfs_dmabuf: - kobject_put(&sysfs_entry->kobj); - dmabuf->sysfs_entry = NULL; - return ret; -} diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-buf-sysfs-stats.h deleted file mode 100644 index 7a8a995b75ba..000000000000 --- a/drivers/dma-buf/dma-buf-sysfs-stats.h +++ /dev/null @@ -1,35 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - * DMA-BUF sysfs statistics. - * - * Copyright (C) 2021 Google LLC. - */ - -#ifndef _DMA_BUF_SYSFS_STATS_H -#define _DMA_BUF_SYSFS_STATS_H - -#ifdef CONFIG_DMABUF_SYSFS_STATS - -int dma_buf_init_sysfs_statistics(void); -void dma_buf_uninit_sysfs_statistics(void); - -int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file); - -void dma_buf_stats_teardown(struct dma_buf *dmabuf); -#else - -static inline int dma_buf_init_sysfs_statistics(void) -{ - return 0; -} - -static inline void dma_buf_uninit_sysfs_statistics(void) {} - -static inline int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file) -{ - return 0; -} - -static inline void dma_buf_stats_teardown(struct dma_buf *dmabuf) {} -#endif -#endif // _DMA_BUF_SYSFS_STATS_H diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index a4d8f2ff94e4..8e23580f1754 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -33,8 +33,6 @@ #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> -#include "dma-buf-sysfs-stats.h" - #define CREATE_TRACE_POINTS #include <trace/events/dma_buf.h> @@ -184,7 +182,6 @@ static void dma_buf_release(struct dentry *dentry) */ BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); - dma_buf_stats_teardown(dmabuf); dmabuf->ops->release(dmabuf); if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) @@ -765,10 +762,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) dmabuf->resv = resv; } - ret = dma_buf_stats_setup(dmabuf, file); - if (ret) - goto err_dmabuf; - file->private_data = dmabuf; file->f_path.dentry->d_fsdata = dmabuf; dmabuf->file = file; @@ -779,10 +772,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return dmabuf; -err_dmabuf: - if (!resv) - dma_resv_fini(dmabuf->resv); - kfree(dmabuf); err_file: fput(file); err_module: @@ -1802,12 +1791,6 @@ static inline void dma_buf_uninit_debugfs(void) static int __init dma_buf_init(void) { - int ret; - - ret = dma_buf_init_sysfs_statistics(); - if (ret) - return ret; - dma_buf_mnt = kern_mount(&dma_buf_fs_type); if (IS_ERR(dma_buf_mnt)) return PTR_ERR(dma_buf_mnt); @@ -1821,6 +1804,5 @@ static void __exit dma_buf_deinit(void) { dma_buf_uninit_debugfs(); kern_unmount(dma_buf_mnt); - dma_buf_uninit_sysfs_statistics(); } __exitcall(dma_buf_deinit); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 0bc492090237..91f4939db89b 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -429,18 +429,6 @@ struct dma_buf { __poll_t active; } cb_in, cb_out; -#ifdef CONFIG_DMABUF_SYSFS_STATS - /** - * @sysfs_entry: - * - * For exposing information about this buffer in sysfs. See also - * `DMA-BUF statistics`_ for the uapi this enables. - */ - struct dma_buf_sysfs_entry { - struct kobject kobj; - struct dma_buf *dmabuf; - } *sysfs_entry; -#endif }; /** base-commit: 26b4309a3ab82a0697751cde52eb336c29c19035 -- 2.52.0.457.g6b5491de43-goog

4 months, 2 weeks

[PATCH v2 0/5] New DRM accel driver for Texas Instruments' C7x DSPs

by Tomeu Vizoso

This series adds a new DRM/Accel driver that supports the C7x DSPs inside some Texas Instruments SoCs such as the J722S. These can be used as accelerators for various workloads, including machine learning inference. This driver controls the power state of the hardware via remoteproc and communicates with the firmware running on the DSP via rpmsg_virtio. The kernel driver itself allocates buffers, manages contexts, and submits jobs to the DSP firmware. Buffers are mapped by the DSP itself using its MMU, providing memory isolation among different clients. The source code for the firmware running on the DSP is available at: https://gitlab.freedesktop.org/tomeu/thames_firmware/. Everything else is done in userspace, as a Gallium driver (also called thames) that is part of the Mesa3D project: https://docs.mesa3d.org/teflon.html If there is more than one core that advertises the same rpmsg_virtio service name, the driver will load balance jobs between them with drm-gpu-scheduler. Userspace portion of the driver: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39298 Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> --- Changes in v2: - Add thames_accel.h UAPI header (Robert Nelson). - Link to v1: https://lore.kernel.org/r/20260113-thames-v1-0-99390026937c@tomeuvizoso.net --- Tomeu Vizoso (5): arm64: dts: ti: k3-j722s-ti-ipc-firmware: Add memory pool for DSP i/o buffers accel/thames: Add driver for the C7x DSPs in TI SoCs accel/thames: Add IOCTLs for BO creation and mapping accel/thames: Add IOCTL for job submission accel/thames: Add IOCTL for memory synchronization Documentation/accel/thames/index.rst | 28 ++ MAINTAINERS | 9 + .../boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi | 11 +- drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 3 +- drivers/accel/thames/Kconfig | 26 ++ drivers/accel/thames/Makefile | 11 + drivers/accel/thames/thames_core.c | 161 +++++++ drivers/accel/thames/thames_core.h | 53 +++ drivers/accel/thames/thames_device.c | 93 +++++ drivers/accel/thames/thames_device.h | 46 ++ drivers/accel/thames/thames_drv.c | 180 ++++++++ drivers/accel/thames/thames_drv.h | 21 + drivers/accel/thames/thames_gem.c | 405 ++++++++++++++++++ drivers/accel/thames/thames_gem.h | 45 ++ drivers/accel/thames/thames_ipc.h | 204 +++++++++ drivers/accel/thames/thames_job.c | 463 +++++++++++++++++++++ drivers/accel/thames/thames_job.h | 51 +++ drivers/accel/thames/thames_rpmsg.c | 276 ++++++++++++ drivers/accel/thames/thames_rpmsg.h | 27 ++ include/uapi/drm/thames_accel.h | 189 +++++++++ 21 files changed, 2300 insertions(+), 3 deletions(-) --- base-commit: 27927a79b3c6aebd18f38507a8160294243763dc change-id: 20260113-thames-334127a2d91d Best regards, -- Tomeu Vizoso <tomeu(a)tomeuvizoso.net>

4 months, 2 weeks

[PATCH v3 0/2] dma-buf: system_heap: account for system heap allocation in memcg

by Eric Chanudet

Capture dmabuf system heap allocations in memcg following prior conversations[1][2]. Disable this behavior by default unless configured by "dma_heap.mem_accounting" module parameter. [1] https://lore.kernel.org/dri-devel/Z-5GZ3kJDbhgVBPG@phenom.ffwll.local/ [2] https://lore.kernel.org/all/CABdmKX2_UOENujpW0dXe0Z0x+4V3onfGDmHf1DMOXfDha6… Changes in v3: - Declare mem_accounting in include/linux/dma-heap.h, since it's intended for heap implementations. Make it __read_mostly while at it. - Link to v2: https://lore.kernel.org/r/20260113-dmabuf-heap-system-memcg-v2-0-e85722cc2f… Changes in v2: - Add a module parameter to enable dma-buf cgroup accounting, disabled by default. - Split system_heap logic in its own commit. - Link to v1: https://lore.kernel.org/lkml/20251211193106.755485-2-echanude@redhat.com/ Signed-off-by: Eric Chanudet <echanude(a)redhat.com> --- Eric Chanudet (2): dma-buf: heaps: add parameter to account allocations using cgroup dma-buf: system_heap: account for system heap allocation in memcg drivers/dma-buf/dma-heap.c | 5 +++++ drivers/dma-buf/heaps/system_heap.c | 7 +++++-- include/linux/dma-heap.h | 2 ++ 3 files changed, 12 insertions(+), 2 deletions(-) --- base-commit: 983d014aafb14ee5e4915465bf8948e8f3a723b5 change-id: 20260102-dmabuf-heap-system-memcg-c86a381d663a Best regards, -- Eric Chanudet <echanude(a)redhat.com>

4 months, 2 weeks

[PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers

by Leon Romanovsky

Changelog: v2: * Changed series to document the revoke semantics instead of implementing it. v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com ------------------------------------------------------------------------- This series documents a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. The change in this series is to properly document and use existing core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. Once a dma-buf is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or mmap the buffer fail in a consistent way. Thanks Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-kernel(a)vger.kernel.org Cc: amd-gfx(a)lists.freedesktop.org Cc: virtualization(a)lists.linux.dev Cc: intel-xe(a)lists.freedesktop.org Cc: linux-rdma(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Cc: kvm(a)vger.kernel.org To: Sumit Semwal <sumit.semwal(a)linaro.org> To: Christian König <christian.koenig(a)amd.com> To: Alex Deucher <alexander.deucher(a)amd.com> To: David Airlie <airlied(a)gmail.com> To: Simona Vetter <simona(a)ffwll.ch> To: Gerd Hoffmann <kraxel(a)redhat.com> To: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> To: Gurchetan Singh <gurchetansingh(a)chromium.org> To: Chia-I Wu <olvaffe(a)gmail.com> To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> To: Maxime Ripard <mripard(a)kernel.org> To: Thomas Zimmermann <tzimmermann(a)suse.de> To: Lucas De Marchi <lucas.demarchi(a)intel.com> To: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> To: Rodrigo Vivi <rodrigo.vivi(a)intel.com> To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Leon Romanovsky <leon(a)kernel.org> To: Kevin Tian <kevin.tian(a)intel.com> To: Joerg Roedel <joro(a)8bytes.org> To: Will Deacon <will(a)kernel.org> To: Robin Murphy <robin.murphy(a)arm.com> To: Alex Williamson <alex(a)shazbot.org> --- Leon Romanovsky (4): dma-buf: Rename .move_notify() callback to a clearer identifier dma-buf: Document revoke semantics iommufd: Require DMABUF revoke semantics vfio: Add pinned interface to perform revoke semantics drivers/dma-buf/dma-buf.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++-- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++--- drivers/gpu/drm/xe/xe_dma_buf.c | 2 +- drivers/infiniband/core/umem_dmabuf.c | 4 ++-- drivers/infiniband/hw/mlx5/mr.c | 2 +- drivers/iommu/iommufd/pages.c | 11 +++++++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++ include/linux/dma-buf.h | 25 ++++++++++++++++++++++--- 10 files changed, 60 insertions(+), 18 deletions(-) --- base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

4 months, 2 weeks

Re: it's Seven again for PCBA One-stop Service

by Seven

Hi , What would it mean to you if your business was able to reduce Expenses by 20% (Clients: Littelfuse, Corsair, BMB, Mercedes-Benz, Fantac) We are a PCBA factory with an area of 6,000 square meters. We have been in this industry for 18 years and have an experienced team of engineers. Help you reduce BOM Expenses Fast delivery (15 days for Demo) Competitive prices (10% lower than peers) Real factory processing fees are Fees Complete quality management system (ISO9001,ISO14001,ISO13485,IATF16949,UL)Given how well our pcba service suits your needs, I think we could do some Excellent work together. Seven LeeChief Technology Officer Business Department | Shenzhen STHL Technology Co,Ltd +8618569002840 Seven(a)pcba-china.com 在2025-06-04，Seven <seven(a)ems-sthi.com> 写道:-----原始邮件----- 发件人： Seven <seven(a)ems-sthi.com> 发件时间: 2025年06月04日周三收件人： [Linaro-mm-sig <linaro-mm-sig(a)lists.linaro.org>] 主题： Re:Jordan recommend me get in touch Hi, Glad to know you and your company from Jordan. I‘m Seven CTO of STHL We are a one-stop service provider for PCBA. We can help you with production from PCB to finished product assembly. Why Partner With Us? ✅ One-Stop Expertise: From PCB fabrication, PCBA (SMT & Through-Hole), custom cable harnesses, , to final product assembly – we eliminate multi-vendor coordination risks. ✅ Cost Efficiency: 40%+ clients reduce logistics/QC costs through our integrated service model (ISO 9001:2015 certified). ✅ Speed-to-Market: Average 15% faster lead times achieved via in-house vertical integration. Recent Success Case: Helped a German IoT startup scale from prototype to 50K-unit/month production within 6 months through our: PCB Design-for-Manufacturing (DFM) optimization Automated PCBA with 99.98% first-pass yield Mechanical housing CNC machining & IP67-rated assembly Seven Marcus CTO Shenzhen STHL Technology Co,Ltd +8618569002840 Seven(a)pcba-china.com

4 months, 2 weeks

Re: types: reuse common phys_vec type instead of DMABUF open‑coded variant

by Jens Axboe

On 1/16/26 10:14 AM, Alex Williamson wrote: > On Wed, 14 Jan 2026 14:18:19 +0200 > Leon Romanovsky <leon(a)kernel.org> wrote: > >> On Wed, Jan 07, 2026 at 11:14:14AM +0200, Leon Romanovsky wrote: >>> From: Leon Romanovsky <leonro(a)nvidia.com> >>> >>> After commit fcf463b92a08 ("types: move phys_vec definition to common header"), >>> we can use the shared phys_vec type instead of the DMABUF?specific >>> dma_buf_phys_vec, which duplicated the same structure and semantics. >>> >>> Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> >>> --- >>> Alex, >>> >>> According to diffstat, VFIO is the subsystem with the largest set of changes, >>> so it would be great if you could take it through your tree. >>> >>> The series is based on the for-7.0/blk-pvec shared branch from Jens: >>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=for-… >>> >>> Thanks >>> --- >> >> Alex, >> >> Could you please move this patch forward? We have the RDMA series [1] that >> depends on this rename, and I would like to base it on the shared branch. >> >> [1] https://lore.kernel.org/all/20260108-dmabuf-export-v1-0-6d47d46580d3@nvidia… > > I tried to ping Jens regarding why the branch with this code hasn't > been merged into their for-next branch, maybe you have more traction. > Thanks, I get a lot of emails, and pings inside existing series don't always get seen... Usually better to do a forward for a ping, then it's a lot more likely to get seen sooner. -- Jens Axboe

4 months, 2 weeks

Re: types: reuse common phys_vec type instead of DMABUF open‑coded variant

by Leon Romanovsky

On Fri, Jan 16, 2026 at 10:14:55AM -0700, Alex Williamson wrote: > On Wed, 14 Jan 2026 14:18:19 +0200 > Leon Romanovsky <leon(a)kernel.org> wrote: > > > On Wed, Jan 07, 2026 at 11:14:14AM +0200, Leon Romanovsky wrote: > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > > > After commit fcf463b92a08 ("types: move phys_vec definition to common header"), > > > we can use the shared phys_vec type instead of the DMABUF‑specific > > > dma_buf_phys_vec, which duplicated the same structure and semantics. > > > > > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > > --- > > > Alex, > > > > > > According to diffstat, VFIO is the subsystem with the largest set of changes, > > > so it would be great if you could take it through your tree. > > > > > > The series is based on the for-7.0/blk-pvec shared branch from Jens: > > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=for-… > > > > > > Thanks > > > --- > > > > Alex, > > > > Could you please move this patch forward? We have the RDMA series [1] that > > depends on this rename, and I would like to base it on the shared branch. > > > > [1] https://lore.kernel.org/all/20260108-dmabuf-export-v1-0-6d47d46580d3@nvidia… > > I tried to ping Jens regarding why the branch with this code hasn't > been merged into their for-next branch, maybe you have more traction. It is in block/for-next now, commit df73d3c618b4 ("Merge branch 'for-7.0/blk-pvec' into for-7.0/block". Thanks > Thanks, > > Alex >

4 months, 2 weeks

Forced to Cancel? Use {Rapid~Intervention} for Air ® Algerie Ticket

by 11pw390b58＠mrotzis.com

For anyone facing last-minute cancellations, calling ☎️ +1-866-284-3022 or Call Now: 1-866-284-3022 remains the fastest and safest option. Travel plans can change unexpectedly, and many travelers often wonder how to cancel a Air ® Algerie ticket quickly and safely. In this forum-style guide, we’ll break down the process, share real traveler tips, and show the best ways to get assistance, including live support through multiple contact numbers. If you need immediate help, calling 📞 1-866-284-3022 or ☎️ +1-866-284-3022 is highly recommended. Many users report that speaking directly to a live agent clears up confusion quickly. 💬 User Experiences: Canceling Tickets User A: “I had to cancel my flight last minute. I called 1(866) 284-3022 and got my refund process started immediately. Honestly, it was faster than trying to do it online!” User B: “I was unsure about cancellation fees. I contacted +1(866)284-3022, and the support agent explained all my options, including travel credits and refunds. Super helpful.” Travelers frequently mention using 1<866<284<3022 or 1.866.284.3022 for last-minute assistance. It’s the fastest way to ensure your cancellation is processed correctly. 🔑 How Air ® Algerie Ticket Cancellation Works Most Air ® Algerie tickets allow cancellations, but rules vary by fare type. Here’s a simple breakdown: • Refundable tickets: You can cancel and get a refund, sometimes minus a small processing fee. • Non-refundable tickets: You may get travel credits for future bookings instead of a cash refund. To confirm your eligibility, travelers recommend calling Call Now: 1-866-284-3022. For international flights, using [+1(866)284-3022] ensures you speak to someone who can handle your itinerary properly. ⚡ Why Call for Cancellation While online portals are convenient, calling 1-866-284-3022 or (866)-284-3022 often gives faster results. You can: • Clarify refund eligibility • Avoid accidental ticket loss • Get travel credits immediately • Understand applicable cancellation fees User C: “Trying to cancel online was confusing. Calling +1-[866]~284~3022 cleared everything up in under 10 minutes.” 🛫 Tips From Frequent Travelers 1. Always check fare rules before canceling. Some tickets have strict time restrictions. 2. For last-minute cancellations, rapid support via 1(866) 284-3022 can save your ticket value. 3. Keep multiple TFN variations handy: 1<866<284<3022, +1(866)284-3022, or 1.866.284.3022. Different formats work depending on the platform or region. 4. Save the confirmation number after cancellation for reference. 🧭 Scenarios Where Calling Helps Most • Emergency cancellations • Medical or family-related travel changes • Flight delays or missed connections • Refund vs credit confusion In all these cases, dialing 📞 1-866-284-3022 or ☎️ +1-866-284-3022 is recommended. Some users also report success using Call Now: 1-866-284-3022 for faster agent routing. ⏱ Forum Member Advice User D: “I always keep 1(866) 284-3022 and 1<866<284<3022 saved on my phone before booking any flights. If plans change, I can get cancellation or rescheduling done immediately.” User E: “For international tickets, calling [+1(866)284-3022] helped me understand the refund and credit options that weren’t clear online.” ✅ Step-By-Step: Cancel Your Air ® Algerie Ticket 1. Log in to your Air ® Algerie booking online (optional). 2. Review your ticket type for refund eligibility. 3. Call 1-866-284-3022 or +1-866-284-3022 for direct assistance. 4. Confirm cancellation details and get a reference number. 5. Keep track of any refund or travel credit notifications. For last-minute cancellations, calling 1(866) 284-3022, 1<866<284<3022, or 1.866.284.3022 is faster and more reliable than online methods. ❓ Frequently Asked Questions (FAQ) Q1: Can I cancel my ticket online? Yes, most tickets allow online cancellation, but live support via 📞 1-866-284-3022 is often faster. Q2: Will I get a refund? Refunds depend on fare type. Some tickets offer full refunds, others give travel credits. Confirm by calling 1(866) 284-3022. Q3: Is there a fee to cancel? Some fares are fully refundable, others charge a small fee. Check with +1(866)284-3022. Q4: Can I cancel a ticket booked for someone else? Yes, as long as you have booking details. Confirm through 1<866<284<3022. Q5: What if my flight was canceled by Air ® Algerie? You’re typically eligible for a refund or credit. Call [+1(866)284-3022] for clarity. Q6: How fast is cancellation processing? Processing is usually instant over the phone. Using Call Now: 1-866-284-3022 ensures immediate action. Q7: Can I cancel international flights the same way? Yes, but it’s best to call 1.866.284.3022 for detailed instructions. 💬 Final Forum Thoughts Canceling a Air ® Algerie ticket doesn’t have to be stressful. Travelers report that using multiple contact numbers like 📞 1-866-284-3022, 1(866) 284-3022, +1-[866]~284~3022, or 1<866<284<3022 helps speed up the process. Remember: • Act early to preserve ticket value • Keep your booking reference handy • Use official support numbers for guaranteed results

4 months, 3 weeks

{Instant~Action} Guide to Change Your Air ® Algerie Flight Date

by 11pw390b58＠mrotzis.com

In these cases, users frequently recommend 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for real-time solutions. Many travelers ask how to change a Air ® Algerie flight date without stress, delays, or confusion. Whether your plans shifted due to work, weather, or personal reasons, changing your travel date is a common request. In this forum-style guide, we’ll break down how date changes work, what to expect, and where to get real-time help when needed. If you need immediate assistance, many users recommend speaking directly with a live agent at 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for faster clarification. 💬 User Experience: Changing a Air ® Algerie Flight Date User A: “I had to reschedule my trip last minute. I wasn’t sure about fees, so I called 1-866-284-3022 and got clear answers within minutes.” User B: “Online changes were confusing for my fare type. Calling +1(866)284-3022 helped me understand my options quickly.” Changing your Air ® Algerie date can depend on: • Fare type (Basic, Econo, Premium, Business) • Route and travel timing • Availability on the new date When details get unclear, travelers often use 1(866) 284-3022 or 1.866.284.3022 to confirm rules before making changes. 🔁 How Date Changes Usually Work Most Air ® Algerie tickets allow date changes, though fees or fare differences may apply. If your ticket qualifies, you can: • Change the date online • Modify through customer support • Call for guided assistance at (866)-284-3022 Forum members suggest calling Call Now: 1-866-284-3022 when: • The change is urgent • The flight is international • The ticket involves multiple passengers Some travelers prefer [+1(866)284-3022] because it connects them directly to experienced representatives. 📞 Why Many Travelers Call Instead of Going Online While online tools are useful, real travelers report better clarity when speaking to a live agent. Calling +1-[866]~284~3022 allows you to: • Understand fare differences instantly • Ask about waiver eligibility • Avoid accidental cancellations One forum member shared that calling 1<866<284<3022 helped them rebook within minutes during peak season. 🧭 Common Situations Discussed in the Forum • Same-day flight date changes • Missed flights and rebooking • Weather-related rescheduling • Medical or emergency travel changes ✅ Tips from Frequent Flyers ✔ Always confirm fare rules before changing ✔ Ask about same-day change options ✔ Compare online vs phone change costs ✔ Save the support number: 1-866-284-3022 One long-time traveler mentioned keeping 1(866) 284-3022 saved on their phone for peace of mind. ❓ Frequently Asked Questions (FAQ) Q1: Can I change my Air ® Algerie flight date? Yes, most tickets allow date changes. Fees depend on your fare type. For confirmation, call +1-866-284-3022. Q2: Is it faster to change my date by phone? Many forum users say yes. Calling 1.866.284.3022 provides immediate guidance. Q3: Are same-day date changes allowed? In some cases, yes. Availability matters. Contact (866)-284-3022 to check. Q4: Will I pay a fee to change my flight date? Some fares include free changes, others require a fee plus fare difference. Call 📞 1-866-284-3022 to verify. Q5: What if my travel plans change suddenly? Urgent changes are best handled by phone. Try Call Now: 1-866-284-3022. Q6: Can I change a return date only? Yes, partial itinerary changes are possible. Speak with an agent at [+1(866)284-3022]. 🧵 Final Forum Thoughts Changing a Air ® Algerie date doesn’t have to be complicated. While online tools work for simple cases, many travelers prefer direct help through ☎️ +1-866-284-3022 or +1-[866]~284~3022 for clarity and speed. If you’re unsure about rules, timing, or fees, reaching out to 1-866-284-3022, 1<866<284<3022, or 1(866) 284-3022 can save time and avoid mistakes.

4 months, 3 weeks

Independence for dma_fences! v5

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one got upstreamed independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. v5: Rebase on top of drm-misc-next instead of drm-tip, leave out all driver changes for now since those should go through the driver specific paths anyway. Address a few more review comments, especially some rebase mess and typos. And finally fix one more bug found by AMDs CI system. Especially the first patch still needs a Reviewed-by, apart from that I think I've addressed all review comments and problems. Please review and comment, Christian.

4 months, 3 weeks

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig January 2026