- Linaro-mm-sig - lists.linaro.org

Re: [PATCH v8 4/4] drm/panthor: show device-wide list of DRM GEM objects over DebugFS

by Steven Price

On 17/04/2025 15:46, Adrián Larumbe wrote: > Hi Steve, > > On 17.04.2025 15:25, Steven Price wrote: >> On 15/04/2025 20:15, Adrián Larumbe wrote: >>> Add a device DebugFS file that displays a complete list of all the DRM >>> GEM objects that are exposed to UM through a DRM handle. >>> >>> Since leaking object identifiers that might belong to a different NS is >>> inadmissible, this functionality is only made available in debug builds >>> with DEBUGFS support enabled. >>> >>> File format is that of a table, with each entry displaying a variety of >>> fields with information about each GEM object. >>> >>> Each GEM object entry in the file displays the following information >>> fields: Client PID, BO's global name, reference count, BO virtual size, >>> BO resize size, VM address in its DRM-managed range, BO label and a GEM >>> state flags. >>> >>> There's also a usage flags field for the type of BO, which tells us >>> whether it's a kernel BO and/or mapped onto the FW's address space. >>> >>> Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> >>> Reviewed-by: Liviu Dudau <liviu.dudau(a)arm.com> >>> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> >> >> Reviewed-by: Steven Price <steven.price(a)arm.com> >> >> Although I feel I have to point out the table output is much wider than >> it needs to be. I'd personally like it if some of the columns were made >> narrower. But I guess the idea is this is going to be read by a script >> anyway. > > In a previous revision, table format was a lot tighter, but Boris > pointed out the number of BO flags might increase in the future, so in > order to save ourselves some headache form having to reformat > everything, it was best to give those fields some extra padding even if > that means BO label spans over the usual screen width. Yeah, fair enough. It's always awkward with this sorts of interfaces. Outputting something very machine readable (e.g. JSON) would be good for scripts, but then it's terrible as a quick debugging aid. I'll just cook up a simple script to reformat it to something I like ;) Thanks, Steve >> Thanks, >> Steve >> >>> --- >>> drivers/gpu/drm/panthor/panthor_device.c | 5 + >>> drivers/gpu/drm/panthor/panthor_device.h | 11 ++ >>> drivers/gpu/drm/panthor/panthor_drv.c | 26 ++++ >>> drivers/gpu/drm/panthor/panthor_gem.c | 182 +++++++++++++++++++++++ >>> drivers/gpu/drm/panthor/panthor_gem.h | 59 ++++++++ >>> 5 files changed, 283 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c >>> index a9da1d1eeb70..b776e1a2e4f3 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_device.c >>> +++ b/drivers/gpu/drm/panthor/panthor_device.c >>> @@ -184,6 +184,11 @@ int panthor_device_init(struct panthor_device *ptdev) >>> if (ret) >>> return ret; >>> >>> +#ifdef CONFIG_DEBUG_FS >>> + drmm_mutex_init(&ptdev->base, &ptdev->gems.lock); >>> + INIT_LIST_HEAD(&ptdev->gems.node); >>> +#endif >>> + >>> atomic_set(&ptdev->pm.state, PANTHOR_DEVICE_PM_STATE_SUSPENDED); >>> p = alloc_page(GFP_KERNEL | __GFP_ZERO); >>> if (!p) >>> diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h >>> index da6574021664..86206a961b38 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_device.h >>> +++ b/drivers/gpu/drm/panthor/panthor_device.h >>> @@ -205,6 +205,17 @@ struct panthor_device { >>> >>> /** @fast_rate: Maximum device clock frequency. Set by DVFS */ >>> unsigned long fast_rate; >>> + >>> +#ifdef CONFIG_DEBUG_FS >>> + /** @gems: Device-wide list of GEM objects owned by at least one file. */ >>> + struct { >>> + /** @gems.lock: Protects the device-wide list of GEM objects. */ >>> + struct mutex lock; >>> + >>> + /** @node: Used to keep track of all the device's DRM objects */ >>> + struct list_head node; >>> + } gems; >>> +#endif >>> }; >>> >>> struct panthor_gpu_usage { >>> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c >>> index 7660627cafa1..13f0b045c5fd 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_drv.c >>> +++ b/drivers/gpu/drm/panthor/panthor_drv.c >>> @@ -1557,9 +1557,35 @@ static const struct file_operations panthor_drm_driver_fops = { >>> }; >>> >>> #ifdef CONFIG_DEBUG_FS >>> +static int panthor_gems_show(struct seq_file *m, void *data) >>> +{ >>> + struct drm_info_node *node = m->private; >>> + struct drm_device *dev = node->minor->dev; >>> + struct panthor_device *ptdev = container_of(dev, struct panthor_device, base); >>> + >>> + panthor_gem_debugfs_print_bos(ptdev, m); >>> + >>> + return 0; >>> +} >>> + >>> + >>> +static struct drm_info_list panthor_debugfs_list[] = { >>> + {"gems", panthor_gems_show, 0, NULL}, >>> +}; >>> + >>> +static int panthor_gems_debugfs_init(struct drm_minor *minor) >>> +{ >>> + drm_debugfs_create_files(panthor_debugfs_list, >>> + ARRAY_SIZE(panthor_debugfs_list), >>> + minor->debugfs_root, minor); >>> + >>> + return 0; >>> +} >>> + >>> static void panthor_debugfs_init(struct drm_minor *minor) >>> { >>> panthor_mmu_debugfs_init(minor); >>> + panthor_gems_debugfs_init(minor); >>> } >>> #endif >>> >>> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c >>> index 3f4ab5a2f2ae..1e3409c05891 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_gem.c >>> +++ b/drivers/gpu/drm/panthor/panthor_gem.c >>> @@ -11,14 +11,51 @@ >>> #include <drm/panthor_drm.h> >>> >>> #include "panthor_device.h" >>> +#include "panthor_fw.h" >>> #include "panthor_gem.h" >>> #include "panthor_mmu.h" >>> >>> +#ifdef CONFIG_DEBUG_FS >>> +static void panthor_gem_debugfs_bo_add(struct panthor_device *ptdev, >>> + struct panthor_gem_object *bo) >>> +{ >>> + INIT_LIST_HEAD(&bo->debugfs.node); >>> + >>> + bo->debugfs.creator.tgid = current->group_leader->pid; >>> + get_task_comm(bo->debugfs.creator.process_name, current->group_leader); >>> + >>> + mutex_lock(&ptdev->gems.lock); >>> + list_add_tail(&bo->debugfs.node, &ptdev->gems.node); >>> + mutex_unlock(&ptdev->gems.lock); >>> +} >>> + >>> +static void panthor_gem_debugfs_bo_rm(struct panthor_gem_object *bo) >>> +{ >>> + struct panthor_device *ptdev = container_of(bo->base.base.dev, >>> + struct panthor_device, base); >>> + >>> + if (list_empty(&bo->debugfs.node)) >>> + return; >>> + >>> + mutex_lock(&ptdev->gems.lock); >>> + list_del_init(&bo->debugfs.node); >>> + mutex_unlock(&ptdev->gems.lock); >>> +} >>> + >>> +#else >>> +static void panthor_gem_debugfs_bo_add(struct panthor_device *ptdev, >>> + struct panthor_gem_object *bo) >>> +{} >>> +static void panthor_gem_debugfs_bo_rm(struct panthor_gem_object *bo) {} >>> +#endif >>> + >>> static void panthor_gem_free_object(struct drm_gem_object *obj) >>> { >>> struct panthor_gem_object *bo = to_panthor_bo(obj); >>> struct drm_gem_object *vm_root_gem = bo->exclusive_vm_root_gem; >>> >>> + panthor_gem_debugfs_bo_rm(bo); >>> + >>> /* >>> * Label might have been allocated with kstrdup_const(), >>> * we need to take that into account when freeing the memory >>> @@ -88,6 +125,7 @@ panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, >>> struct drm_gem_shmem_object *obj; >>> struct panthor_kernel_bo *kbo; >>> struct panthor_gem_object *bo; >>> + u32 debug_flags = PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL; >>> int ret; >>> >>> if (drm_WARN_ON(&ptdev->base, !vm)) >>> @@ -107,7 +145,11 @@ panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, >>> kbo->obj = &obj->base; >>> bo->flags = bo_flags; >>> >>> + if (vm == panthor_fw_vm(ptdev)) >>> + debug_flags |= PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED; >>> + >>> panthor_gem_kernel_bo_set_label(kbo, name); >>> + panthor_gem_debugfs_set_usage_flags(to_panthor_bo(kbo->obj), debug_flags); >>> >>> /* The system and GPU MMU page size might differ, which becomes a >>> * problem for FW sections that need to be mapped at explicit address >>> @@ -210,6 +252,8 @@ struct drm_gem_object *panthor_gem_create_object(struct drm_device *ddev, size_t >>> drm_gem_gpuva_set_lock(&obj->base.base, &obj->gpuva_list_lock); >>> mutex_init(&obj->label.lock); >>> >>> + panthor_gem_debugfs_bo_add(ptdev, obj); >>> + >>> return &obj->base.base; >>> } >>> >>> @@ -258,6 +302,12 @@ panthor_gem_create_with_handle(struct drm_file *file, >>> /* drop reference from allocate - handle holds it now. */ >>> drm_gem_object_put(&shmem->base); >>> >>> + /* >>> + * No explicit flags are needed in the call below, since the >>> + * function internally sets the INITIALIZED bit for us. >>> + */ >>> + panthor_gem_debugfs_set_usage_flags(bo, 0); >>> + >>> return ret; >>> } >>> >>> @@ -296,3 +346,135 @@ panthor_gem_kernel_bo_set_label(struct panthor_kernel_bo *bo, const char *label) >>> >>> panthor_gem_bo_set_label(bo->obj, str); >>> } >>> + >>> +#ifdef CONFIG_DEBUG_FS >>> +static void >>> +panthor_gem_debugfs_format_flags(char flags_str[], int flags_len, >>> + const char * const names[], u32 name_count, >>> + u32 flags) >>> +{ >>> + bool first = true; >>> + int offset = 0; >>> + >>> +#define ACC_FLAGS(...) \ >>> + ({ \ >>> + offset += snprintf(flags_str + offset, flags_len - offset, ##__VA_ARGS__); \ >>> + if (offset == flags_len) \ >>> + return; \ >>> + }) >>> + >>> + ACC_FLAGS("%c", '('); >>> + >>> + if (!flags) >>> + ACC_FLAGS("%s", "none"); >>> + >>> + while (flags) { >>> + u32 bit = fls(flags) - 1; >>> + u32 idx = bit + 1; >>> + >>> + if (!first) >>> + ACC_FLAGS("%s", ","); >>> + >>> + if (idx < name_count && names[idx]) >>> + ACC_FLAGS("%s", names[idx]); >>> + >>> + first = false; >>> + flags &= ~BIT(bit); >>> + } >>> + >>> + ACC_FLAGS("%c", ')'); >>> + >>> +#undef ACC_FLAGS >>> +} >>> + >>> +struct gem_size_totals { >>> + size_t size; >>> + size_t resident; >>> + size_t reclaimable; >>> +}; >>> + >>> +static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo, >>> + struct seq_file *m, >>> + struct gem_size_totals *totals) >>> +{ >>> + unsigned int refcount = kref_read(&bo->base.base.refcount); >>> + char creator_info[32] = {}; >>> + size_t resident_size; >>> + char gem_state_str[64] = {}; >>> + char gem_usage_str[64] = {}; >>> + u32 gem_usage_flags = bo->debugfs.flags & (u32)~PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED; >>> + u32 gem_state_flags = 0; >>> + >>> + static const char * const gem_state_flags_names[] = { >>> + [PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED] = "imported", >>> + [PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED] = "exported", >>> + }; >>> + >>> + static const char * const gem_usage_flags_names[] = { >>> + [PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL] = "kernel", >>> + [PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED] = "fw-mapped", >>> + }; >>> + >>> + /* Skip BOs being destroyed. */ >>> + if (!refcount) >>> + return; >>> + >>> + resident_size = bo->base.pages != NULL ? bo->base.base.size : 0; >>> + >>> + snprintf(creator_info, sizeof(creator_info), >>> + "%s/%d", bo->debugfs.creator.process_name, bo->debugfs.creator.tgid); >>> + seq_printf(m, "%-32s%-16d%-16d%-16zd%-16zd%-16lx", >>> + creator_info, >>> + bo->base.base.name, >>> + refcount, >>> + bo->base.base.size, >>> + resident_size, >>> + drm_vma_node_start(&bo->base.base.vma_node)); >>> + >>> + if (bo->base.base.import_attach != NULL) >>> + gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED; >>> + if (bo->base.base.dma_buf != NULL) >>> + gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED; >>> + >>> + panthor_gem_debugfs_format_flags(gem_state_str, sizeof(gem_state_str), >>> + gem_state_flags_names, ARRAY_SIZE(gem_state_flags_names), >>> + gem_state_flags); >>> + panthor_gem_debugfs_format_flags(gem_usage_str, sizeof(gem_usage_str), >>> + gem_usage_flags_names, ARRAY_SIZE(gem_usage_flags_names), >>> + gem_usage_flags); >>> + >>> + seq_printf(m, "%-64s%-64s", gem_state_str, gem_usage_str); >>> + >>> + scoped_guard(mutex, &bo->label.lock) { >>> + seq_printf(m, "%s", bo->label.str ? : ""); >>> + } >>> + >>> + seq_puts(m, "\n"); >>> + >>> + totals->size += bo->base.base.size; >>> + totals->resident += resident_size; >>> + if (bo->base.madv > 0) >>> + totals->reclaimable += resident_size; >>> +} >>> + >>> +void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev, >>> + struct seq_file *m) >>> +{ >>> + struct gem_size_totals totals = {0}; >>> + struct panthor_gem_object *bo; >>> + >>> + seq_puts(m, "created-by global-name refcount size resident-size file-offset state usage label\n"); >>> + seq_puts(m, "-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n"); >>> + >>> + scoped_guard(mutex, &ptdev->gems.lock) { >>> + list_for_each_entry(bo, &ptdev->gems.node, debugfs.node) { >>> + if (bo->debugfs.flags & PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED) >>> + panthor_gem_debugfs_bo_print(bo, m, &totals); >>> + } >>> + } >>> + >>> + seq_puts(m, "=====================================================================================================================================================================================================================================================\n"); >>> + seq_printf(m, "Total size: %zd, Total resident: %zd, Total reclaimable: %zd\n", >>> + totals.size, totals.resident, totals.reclaimable); >>> +} >>> +#endif >>> diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h >>> index 3c09af568e47..94b244f0540e 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_gem.h >>> +++ b/drivers/gpu/drm/panthor/panthor_gem.h >>> @@ -15,6 +15,48 @@ struct panthor_vm; >>> >>> #define PANTHOR_BO_LABEL_MAXLEN 4096 >>> >>> +enum panthor_debugfs_gem_state_flags { >>> + /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED: GEM BO is PRIME imported. */ >>> + PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED = BIT(0), >>> + >>> + /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED: GEM BO is PRIME exported. */ >>> + PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED = BIT(1), >>> +}; >>> + >>> +enum panthor_debugfs_gem_usage_flags { >>> + /** @PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL: BO is for kernel use only. */ >>> + PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL = BIT(0), >>> + >>> + /** @PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED: BO is mapped on the FW VM. */ >>> + PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED = BIT(1), >>> + >>> + /** @PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED: BO is ready for DebugFS display. */ >>> + PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED = BIT(31), >>> +}; >>> + >>> +/** >>> + * struct panthor_gem_debugfs - GEM object's DebugFS list information >>> + */ >>> +struct panthor_gem_debugfs { >>> + /** >>> + * @node: Node used to insert the object in the device-wide list of >>> + * GEM objects, to display information about it through a DebugFS file. >>> + */ >>> + struct list_head node; >>> + >>> + /** @creator: Information about the UM process which created the GEM. */ >>> + struct { >>> + /** @creator.process_name: Group leader name in owning thread's process */ >>> + char process_name[TASK_COMM_LEN]; >>> + >>> + /** @creator.tgid: PID of the thread's group leader within its process */ >>> + pid_t tgid; >>> + } creator; >>> + >>> + /** @flags: Combination of panthor_debugfs_gem_usage_flags flags */ >>> + u32 flags; >>> +}; >>> + >>> /** >>> * struct panthor_gem_object - Driver specific GEM object. >>> */ >>> @@ -62,6 +104,10 @@ struct panthor_gem_object { >>> /** @lock.str: Protects access to the @label.str field. */ >>> struct mutex lock; >>> } label; >>> + >>> +#ifdef CONFIG_DEBUG_FS >>> + struct panthor_gem_debugfs debugfs; >>> +#endif >>> }; >>> >>> /** >>> @@ -157,4 +203,17 @@ panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, >>> >>> void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo); >>> >>> +#ifdef CONFIG_DEBUG_FS >>> +void panthor_gem_debugfs_print_bos(struct panthor_device *pfdev, >>> + struct seq_file *m); >>> +static inline void >>> +panthor_gem_debugfs_set_usage_flags(struct panthor_gem_object *bo, u32 usage_flags) >>> +{ >>> + bo->debugfs.flags = usage_flags | PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED; >>> +} >>> + >>> +#else >>> +void panthor_gem_debugfs_set_usage_flags(struct panthor_gem_object *bo, u32 usage_flags) {}; >>> +#endif >>> + >>> #endif /* __PANTHOR_GEM_H__ */ > > Adrian Larumbe

8 months

1
0
0 0

Re: [PATCH v8 4/4] drm/panthor: show device-wide list of DRM GEM objects over DebugFS

by Steven Price

On 15/04/2025 20:15, Adrián Larumbe wrote: > Add a device DebugFS file that displays a complete list of all the DRM > GEM objects that are exposed to UM through a DRM handle. > > Since leaking object identifiers that might belong to a different NS is > inadmissible, this functionality is only made available in debug builds > with DEBUGFS support enabled. > > File format is that of a table, with each entry displaying a variety of > fields with information about each GEM object. > > Each GEM object entry in the file displays the following information > fields: Client PID, BO's global name, reference count, BO virtual size, > BO resize size, VM address in its DRM-managed range, BO label and a GEM > state flags. > > There's also a usage flags field for the type of BO, which tells us > whether it's a kernel BO and/or mapped onto the FW's address space. > > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > Reviewed-by: Liviu Dudau <liviu.dudau(a)arm.com> > Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> Reviewed-by: Steven Price <steven.price(a)arm.com> Although I feel I have to point out the table output is much wider than it needs to be. I'd personally like it if some of the columns were made narrower. But I guess the idea is this is going to be read by a script anyway. Thanks, Steve > --- > drivers/gpu/drm/panthor/panthor_device.c | 5 + > drivers/gpu/drm/panthor/panthor_device.h | 11 ++ > drivers/gpu/drm/panthor/panthor_drv.c | 26 ++++ > drivers/gpu/drm/panthor/panthor_gem.c | 182 +++++++++++++++++++++++ > drivers/gpu/drm/panthor/panthor_gem.h | 59 ++++++++ > 5 files changed, 283 insertions(+) > > diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c > index a9da1d1eeb70..b776e1a2e4f3 100644 > --- a/drivers/gpu/drm/panthor/panthor_device.c > +++ b/drivers/gpu/drm/panthor/panthor_device.c > @@ -184,6 +184,11 @@ int panthor_device_init(struct panthor_device *ptdev) > if (ret) > return ret; > > +#ifdef CONFIG_DEBUG_FS > + drmm_mutex_init(&ptdev->base, &ptdev->gems.lock); > + INIT_LIST_HEAD(&ptdev->gems.node); > +#endif > + > atomic_set(&ptdev->pm.state, PANTHOR_DEVICE_PM_STATE_SUSPENDED); > p = alloc_page(GFP_KERNEL | __GFP_ZERO); > if (!p) > diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h > index da6574021664..86206a961b38 100644 > --- a/drivers/gpu/drm/panthor/panthor_device.h > +++ b/drivers/gpu/drm/panthor/panthor_device.h > @@ -205,6 +205,17 @@ struct panthor_device { > > /** @fast_rate: Maximum device clock frequency. Set by DVFS */ > unsigned long fast_rate; > + > +#ifdef CONFIG_DEBUG_FS > + /** @gems: Device-wide list of GEM objects owned by at least one file. */ > + struct { > + /** @gems.lock: Protects the device-wide list of GEM objects. */ > + struct mutex lock; > + > + /** @node: Used to keep track of all the device's DRM objects */ > + struct list_head node; > + } gems; > +#endif > }; > > struct panthor_gpu_usage { > diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c > index 7660627cafa1..13f0b045c5fd 100644 > --- a/drivers/gpu/drm/panthor/panthor_drv.c > +++ b/drivers/gpu/drm/panthor/panthor_drv.c > @@ -1557,9 +1557,35 @@ static const struct file_operations panthor_drm_driver_fops = { > }; > > #ifdef CONFIG_DEBUG_FS > +static int panthor_gems_show(struct seq_file *m, void *data) > +{ > + struct drm_info_node *node = m->private; > + struct drm_device *dev = node->minor->dev; > + struct panthor_device *ptdev = container_of(dev, struct panthor_device, base); > + > + panthor_gem_debugfs_print_bos(ptdev, m); > + > + return 0; > +} > + > + > +static struct drm_info_list panthor_debugfs_list[] = { > + {"gems", panthor_gems_show, 0, NULL}, > +}; > + > +static int panthor_gems_debugfs_init(struct drm_minor *minor) > +{ > + drm_debugfs_create_files(panthor_debugfs_list, > + ARRAY_SIZE(panthor_debugfs_list), > + minor->debugfs_root, minor); > + > + return 0; > +} > + > static void panthor_debugfs_init(struct drm_minor *minor) > { > panthor_mmu_debugfs_init(minor); > + panthor_gems_debugfs_init(minor); > } > #endif > > diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c > index 3f4ab5a2f2ae..1e3409c05891 100644 > --- a/drivers/gpu/drm/panthor/panthor_gem.c > +++ b/drivers/gpu/drm/panthor/panthor_gem.c > @@ -11,14 +11,51 @@ > #include <drm/panthor_drm.h> > > #include "panthor_device.h" > +#include "panthor_fw.h" > #include "panthor_gem.h" > #include "panthor_mmu.h" > > +#ifdef CONFIG_DEBUG_FS > +static void panthor_gem_debugfs_bo_add(struct panthor_device *ptdev, > + struct panthor_gem_object *bo) > +{ > + INIT_LIST_HEAD(&bo->debugfs.node); > + > + bo->debugfs.creator.tgid = current->group_leader->pid; > + get_task_comm(bo->debugfs.creator.process_name, current->group_leader); > + > + mutex_lock(&ptdev->gems.lock); > + list_add_tail(&bo->debugfs.node, &ptdev->gems.node); > + mutex_unlock(&ptdev->gems.lock); > +} > + > +static void panthor_gem_debugfs_bo_rm(struct panthor_gem_object *bo) > +{ > + struct panthor_device *ptdev = container_of(bo->base.base.dev, > + struct panthor_device, base); > + > + if (list_empty(&bo->debugfs.node)) > + return; > + > + mutex_lock(&ptdev->gems.lock); > + list_del_init(&bo->debugfs.node); > + mutex_unlock(&ptdev->gems.lock); > +} > + > +#else > +static void panthor_gem_debugfs_bo_add(struct panthor_device *ptdev, > + struct panthor_gem_object *bo) > +{} > +static void panthor_gem_debugfs_bo_rm(struct panthor_gem_object *bo) {} > +#endif > + > static void panthor_gem_free_object(struct drm_gem_object *obj) > { > struct panthor_gem_object *bo = to_panthor_bo(obj); > struct drm_gem_object *vm_root_gem = bo->exclusive_vm_root_gem; > > + panthor_gem_debugfs_bo_rm(bo); > + > /* > * Label might have been allocated with kstrdup_const(), > * we need to take that into account when freeing the memory > @@ -88,6 +125,7 @@ panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, > struct drm_gem_shmem_object *obj; > struct panthor_kernel_bo *kbo; > struct panthor_gem_object *bo; > + u32 debug_flags = PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL; > int ret; > > if (drm_WARN_ON(&ptdev->base, !vm)) > @@ -107,7 +145,11 @@ panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, > kbo->obj = &obj->base; > bo->flags = bo_flags; > > + if (vm == panthor_fw_vm(ptdev)) > + debug_flags |= PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED; > + > panthor_gem_kernel_bo_set_label(kbo, name); > + panthor_gem_debugfs_set_usage_flags(to_panthor_bo(kbo->obj), debug_flags); > > /* The system and GPU MMU page size might differ, which becomes a > * problem for FW sections that need to be mapped at explicit address > @@ -210,6 +252,8 @@ struct drm_gem_object *panthor_gem_create_object(struct drm_device *ddev, size_t > drm_gem_gpuva_set_lock(&obj->base.base, &obj->gpuva_list_lock); > mutex_init(&obj->label.lock); > > + panthor_gem_debugfs_bo_add(ptdev, obj); > + > return &obj->base.base; > } > > @@ -258,6 +302,12 @@ panthor_gem_create_with_handle(struct drm_file *file, > /* drop reference from allocate - handle holds it now. */ > drm_gem_object_put(&shmem->base); > > + /* > + * No explicit flags are needed in the call below, since the > + * function internally sets the INITIALIZED bit for us. > + */ > + panthor_gem_debugfs_set_usage_flags(bo, 0); > + > return ret; > } > > @@ -296,3 +346,135 @@ panthor_gem_kernel_bo_set_label(struct panthor_kernel_bo *bo, const char *label) > > panthor_gem_bo_set_label(bo->obj, str); > } > + > +#ifdef CONFIG_DEBUG_FS > +static void > +panthor_gem_debugfs_format_flags(char flags_str[], int flags_len, > + const char * const names[], u32 name_count, > + u32 flags) > +{ > + bool first = true; > + int offset = 0; > + > +#define ACC_FLAGS(...) \ > + ({ \ > + offset += snprintf(flags_str + offset, flags_len - offset, ##__VA_ARGS__); \ > + if (offset == flags_len) \ > + return; \ > + }) > + > + ACC_FLAGS("%c", '('); > + > + if (!flags) > + ACC_FLAGS("%s", "none"); > + > + while (flags) { > + u32 bit = fls(flags) - 1; > + u32 idx = bit + 1; > + > + if (!first) > + ACC_FLAGS("%s", ","); > + > + if (idx < name_count && names[idx]) > + ACC_FLAGS("%s", names[idx]); > + > + first = false; > + flags &= ~BIT(bit); > + } > + > + ACC_FLAGS("%c", ')'); > + > +#undef ACC_FLAGS > +} > + > +struct gem_size_totals { > + size_t size; > + size_t resident; > + size_t reclaimable; > +}; > + > +static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo, > + struct seq_file *m, > + struct gem_size_totals *totals) > +{ > + unsigned int refcount = kref_read(&bo->base.base.refcount); > + char creator_info[32] = {}; > + size_t resident_size; > + char gem_state_str[64] = {}; > + char gem_usage_str[64] = {}; > + u32 gem_usage_flags = bo->debugfs.flags & (u32)~PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED; > + u32 gem_state_flags = 0; > + > + static const char * const gem_state_flags_names[] = { > + [PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED] = "imported", > + [PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED] = "exported", > + }; > + > + static const char * const gem_usage_flags_names[] = { > + [PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL] = "kernel", > + [PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED] = "fw-mapped", > + }; > + > + /* Skip BOs being destroyed. */ > + if (!refcount) > + return; > + > + resident_size = bo->base.pages != NULL ? bo->base.base.size : 0; > + > + snprintf(creator_info, sizeof(creator_info), > + "%s/%d", bo->debugfs.creator.process_name, bo->debugfs.creator.tgid); > + seq_printf(m, "%-32s%-16d%-16d%-16zd%-16zd%-16lx", > + creator_info, > + bo->base.base.name, > + refcount, > + bo->base.base.size, > + resident_size, > + drm_vma_node_start(&bo->base.base.vma_node)); > + > + if (bo->base.base.import_attach != NULL) > + gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED; > + if (bo->base.base.dma_buf != NULL) > + gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED; > + > + panthor_gem_debugfs_format_flags(gem_state_str, sizeof(gem_state_str), > + gem_state_flags_names, ARRAY_SIZE(gem_state_flags_names), > + gem_state_flags); > + panthor_gem_debugfs_format_flags(gem_usage_str, sizeof(gem_usage_str), > + gem_usage_flags_names, ARRAY_SIZE(gem_usage_flags_names), > + gem_usage_flags); > + > + seq_printf(m, "%-64s%-64s", gem_state_str, gem_usage_str); > + > + scoped_guard(mutex, &bo->label.lock) { > + seq_printf(m, "%s", bo->label.str ? : ""); > + } > + > + seq_puts(m, "\n"); > + > + totals->size += bo->base.base.size; > + totals->resident += resident_size; > + if (bo->base.madv > 0) > + totals->reclaimable += resident_size; > +} > + > +void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev, > + struct seq_file *m) > +{ > + struct gem_size_totals totals = {0}; > + struct panthor_gem_object *bo; > + > + seq_puts(m, "created-by global-name refcount size resident-size file-offset state usage label\n"); > + seq_puts(m, "-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n"); > + > + scoped_guard(mutex, &ptdev->gems.lock) { > + list_for_each_entry(bo, &ptdev->gems.node, debugfs.node) { > + if (bo->debugfs.flags & PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED) > + panthor_gem_debugfs_bo_print(bo, m, &totals); > + } > + } > + > + seq_puts(m, "=====================================================================================================================================================================================================================================================\n"); > + seq_printf(m, "Total size: %zd, Total resident: %zd, Total reclaimable: %zd\n", > + totals.size, totals.resident, totals.reclaimable); > +} > +#endif > diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h > index 3c09af568e47..94b244f0540e 100644 > --- a/drivers/gpu/drm/panthor/panthor_gem.h > +++ b/drivers/gpu/drm/panthor/panthor_gem.h > @@ -15,6 +15,48 @@ struct panthor_vm; > > #define PANTHOR_BO_LABEL_MAXLEN 4096 > > +enum panthor_debugfs_gem_state_flags { > + /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED: GEM BO is PRIME imported. */ > + PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED = BIT(0), > + > + /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED: GEM BO is PRIME exported. */ > + PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED = BIT(1), > +}; > + > +enum panthor_debugfs_gem_usage_flags { > + /** @PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL: BO is for kernel use only. */ > + PANTHOR_DEBUGFS_GEM_USAGE_FLAG_KERNEL = BIT(0), > + > + /** @PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED: BO is mapped on the FW VM. */ > + PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED = BIT(1), > + > + /** @PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED: BO is ready for DebugFS display. */ > + PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED = BIT(31), > +}; > + > +/** > + * struct panthor_gem_debugfs - GEM object's DebugFS list information > + */ > +struct panthor_gem_debugfs { > + /** > + * @node: Node used to insert the object in the device-wide list of > + * GEM objects, to display information about it through a DebugFS file. > + */ > + struct list_head node; > + > + /** @creator: Information about the UM process which created the GEM. */ > + struct { > + /** @creator.process_name: Group leader name in owning thread's process */ > + char process_name[TASK_COMM_LEN]; > + > + /** @creator.tgid: PID of the thread's group leader within its process */ > + pid_t tgid; > + } creator; > + > + /** @flags: Combination of panthor_debugfs_gem_usage_flags flags */ > + u32 flags; > +}; > + > /** > * struct panthor_gem_object - Driver specific GEM object. > */ > @@ -62,6 +104,10 @@ struct panthor_gem_object { > /** @lock.str: Protects access to the @label.str field. */ > struct mutex lock; > } label; > + > +#ifdef CONFIG_DEBUG_FS > + struct panthor_gem_debugfs debugfs; > +#endif > }; > > /** > @@ -157,4 +203,17 @@ panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, > > void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo); > > +#ifdef CONFIG_DEBUG_FS > +void panthor_gem_debugfs_print_bos(struct panthor_device *pfdev, > + struct seq_file *m); > +static inline void > +panthor_gem_debugfs_set_usage_flags(struct panthor_gem_object *bo, u32 usage_flags) > +{ > + bo->debugfs.flags = usage_flags | PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED; > +} > + > +#else > +void panthor_gem_debugfs_set_usage_flags(struct panthor_gem_object *bo, u32 usage_flags) {}; > +#endif > + > #endif /* __PANTHOR_GEM_H__ */

8 months

1
0
0 0

Re: [PATCH] dma-buf: heaps: Set allocation orders for larger page sizes

by Christian König

Am 16.04.25 um 23:51 schrieb Juan Yescas: > On Wed, Apr 16, 2025 at 4:34 AM Christian König > <christian.koenig(a)amd.com> wrote: >> >> >> Am 15.04.25 um 19:19 schrieb Juan Yescas: >>> This change sets the allocation orders for the different page sizes >>> (4k, 16k, 64k) based on PAGE_SHIFT. Before this change, the orders >>> for large page sizes were calculated incorrectly, this caused system >>> heap to allocate from 2% to 4% more memory on 16KiB page size kernels. >>> >>> This change was tested on 4k/16k page size kernels. >>> >>> Signed-off-by: Juan Yescas <jyescas(a)google.com> >>> --- >>> drivers/dma-buf/heaps/system_heap.c | 9 ++++++++- >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c >>> index 26d5dc89ea16..54674c02dcb4 100644 >>> --- a/drivers/dma-buf/heaps/system_heap.c >>> +++ b/drivers/dma-buf/heaps/system_heap.c >>> @@ -50,8 +50,15 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; >>> * to match with the sizes often found in IOMMUs. Using order 4 pages instead >>> * of order 0 pages can significantly improve the performance of many IOMMUs >>> * by reducing TLB pressure and time spent updating page tables. >>> + * >>> + * Note: When the order is 0, the minimum allocation is PAGE_SIZE. The possible >>> + * page sizes for ARM devices could be 4K, 16K and 64K. >>> */ >>> -static const unsigned int orders[] = {8, 4, 0}; >>> +#define ORDER_1M (20 - PAGE_SHIFT) >>> +#define ORDER_64K (16 - PAGE_SHIFT) >>> +#define ORDER_FOR_PAGE_SIZE (0) >>> +static const unsigned int orders[] = {ORDER_1M, ORDER_64K, ORDER_FOR_PAGE_SIZE}; >>> +# >> Good catch, but I think the defines are just overkill. >> >> What you should do instead is to subtract page shift when using the array. >> > There are several occurrences of orders in the file and I think it is > better to do the calculations up front in the array. Would you be ok > if we get rid of the defines as per your suggestion and make the > calculations during the definition of the array. Something like this: > > static const unsigned int orders[] = {20 - PAGE_SHIFT, 16 - PAGE_SHIFT, 0}; Yeah that totally works for me as well. Just make sure that a code comment nearby explains why 20, 16 and 0. >> Apart from that using 1M, 64K and then falling back to 4K just sounds random to me. We have especially pushed back on 64K more than once because it is actually not beneficial in almost all cases. >> > In the hardware where the driver is used, the 64K is beneficial for: > > Arm SMMUv3 (4KB granule size): > 64KB (contiguous bit groups 16 4KB pages) > > SysMMU benefits from 64KB (“large” page) on 4k/16k page sizes. Question could this HW also work with pages larger than 64K? (I strongly expect yes). >> I suggest to fix the code in system_heap_allocate to not over allocate instead and just try the available orders like TTM does. This has proven to be working architecture independent. >> > Do you mean to have an implementation similar to __ttm_pool_alloc()? Yeah something like that. > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree… > > If that is the case, we can try the change, run some benchmarks and > submit the patch if we see positive results. Could be that this doesn't matter for your platform, but it's minimal extra overhead asking for larger chunks first and it just avoids fragmenting everything into 64K chunks. That is kind of important since the code in DMA-heaps should be platform neutral if possible. Regards, Christian. > > Thanks > Juan > >> Regards, >> Christian. >> >>> #define NUM_ORDERS ARRAY_SIZE(orders) >>> >>> static struct sg_table *dup_sg_table(struct sg_table *table)

8 months

1
0
0 0

Re: [PATCH 2/4] bpf: Add dmabuf iterator

by T.J. Mercier

On Wed, Apr 16, 2025 at 6:26 PM Song Liu <song(a)kernel.org> wrote: > > On Wed, Apr 16, 2025 at 4:40 PM T.J. Mercier <tjmercier(a)google.com> wrote: > > > > On Wed, Apr 16, 2025 at 4:08 PM Song Liu <song(a)kernel.org> wrote: > > > > > > On Wed, Apr 16, 2025 at 3:51 PM T.J. Mercier <tjmercier(a)google.com> wrote: > > > [...] > > > > > > > > > > IIUC, the iterator simply traverses elements in a linked list. I feel it is > > > > > an overkill to implement a new BPF iterator for it. > > > > > > > > Like other BPF iterators such as kmem_cache_iter or task_iter. > > > > Cgroup_iter iterates trees instead of lists. This is iterating over > > > > kernel objects just like the docs say, "A BPF iterator is a type of > > > > BPF program that allows users to iterate over specific types of kernel > > > > objects". More complicated iteration should not be a requirement here. > > > > > > > > > Maybe we simply > > > > > use debugging tools like crash or drgn for this? The access with > > > > > these tools will not be protected by the mutex. But from my personal > > > > > experience, this is not a big issue for user space debugging tools. > > > > > > > > drgn is *way* too slow, and even if it weren't the dependencies for > > > > running it aren't available. crash needs debug symbols which also > > > > aren't available on user builds. This is not just for manual > > > > debugging, it's for reporting memory use in production. Or anything > > > > else someone might care to extract like attachment info or refcounts. > > > > > > Could you please share more information about the use cases and > > > the time constraint here, and why drgn is too slow. Is most of the delay > > > comes from parsing DWARF? This is mostly for my curiosity, because > > > I have been thinking about using drgn to do some monitoring in > > > production. > > > > > > Thanks, > > > Song > > > > These RunCommands have 10 second timeouts for example. It's rare that > > I see them get exceeded but it happens occasionally.: > > https://cs.android.com/android/platform/superproject/main/+/main:frameworks… > > Thanks for sharing this information. > > > The last time I used drgn (admittedly back in 2023) it took over a > > minute to iterate through less than 200 cgroups. I'm not sure what the > > root cause of the slowness was, but I'd expect the DWARF processing to > > be done up-front once and the slowness I experienced was not just at > > startup. Eventually I switched over to tracefs for that issue, which > > we still use for some telemetry. > > I haven't tried drgn on Android. On server side, iterating should 200 > cgroups should be fairly fast (< 5 seconds, where DWARF parsing is > the most expensive part). > > > Other uses are by statsd for telemetry, memory reporting on app kills > > or death, and for "dumpsys meminfo". > > Here is another rookie question, it appears to me there is a file descriptor > associated with each DMA buffer, can we achieve the same goal with > a task-file iterator? That would find almost all of them, but not the kernel-only allocations. (kernel_rss in the dmabuf_dump output I attached earlier. If there's a leak, it's likely to show up in kernel_rss because some driver forgot to release its reference(s).) Also wouldn't that be a ton more iterations since we'd have to visit every FD to find the small portion that are dmabufs? I'm not actually sure if buffers that have been mapped, and then have had their file descriptors closed would show up in task_struct->files; if not I think that would mean scanning both files and vmas for each task.

8 months

1
0
0 0

Re: [PATCH 2/4] bpf: Add dmabuf iterator

by T.J. Mercier

On Wed, Apr 16, 2025 at 4:08 PM Song Liu <song(a)kernel.org> wrote: > > On Wed, Apr 16, 2025 at 3:51 PM T.J. Mercier <tjmercier(a)google.com> wrote: > [...] > > > > > > IIUC, the iterator simply traverses elements in a linked list. I feel it is > > > an overkill to implement a new BPF iterator for it. > > > > Like other BPF iterators such as kmem_cache_iter or task_iter. > > Cgroup_iter iterates trees instead of lists. This is iterating over > > kernel objects just like the docs say, "A BPF iterator is a type of > > BPF program that allows users to iterate over specific types of kernel > > objects". More complicated iteration should not be a requirement here. > > > > > Maybe we simply > > > use debugging tools like crash or drgn for this? The access with > > > these tools will not be protected by the mutex. But from my personal > > > experience, this is not a big issue for user space debugging tools. > > > > drgn is *way* too slow, and even if it weren't the dependencies for > > running it aren't available. crash needs debug symbols which also > > aren't available on user builds. This is not just for manual > > debugging, it's for reporting memory use in production. Or anything > > else someone might care to extract like attachment info or refcounts. > > Could you please share more information about the use cases and > the time constraint here, and why drgn is too slow. Is most of the delay > comes from parsing DWARF? This is mostly for my curiosity, because > I have been thinking about using drgn to do some monitoring in > production. > > Thanks, > Song These RunCommands have 10 second timeouts for example. It's rare that I see them get exceeded but it happens occasionally.: https://cs.android.com/android/platform/superproject/main/+/main:frameworks… The last time I used drgn (admittedly back in 2023) it took over a minute to iterate through less than 200 cgroups. I'm not sure what the root cause of the slowness was, but I'd expect the DWARF processing to be done up-front once and the slowness I experienced was not just at startup. Eventually I switched over to tracefs for that issue, which we still use for some telemetry. Other uses are by statsd for telemetry, memory reporting on app kills or death, and for "dumpsys meminfo". Thanks, T.J.

8 months

1
0
0 0

Re: [PATCH 2/4] bpf: Add dmabuf iterator

by T.J. Mercier

On Wed, Apr 16, 2025 at 3:02 PM Song Liu <song(a)kernel.org> wrote: > > On Mon, Apr 14, 2025 at 3:53 PM T.J. Mercier <tjmercier(a)google.com> wrote: > [...] > > + > > +BTF_ID_LIST_GLOBAL_SINGLE(bpf_dmabuf_btf_id, struct, dma_buf) > > +DEFINE_BPF_ITER_FUNC(dmabuf, struct bpf_iter_meta *meta, struct dma_buf *dmabuf) > > + > > +static void *dmabuf_iter_seq_start(struct seq_file *seq, loff_t *pos) > > +{ > > + struct dma_buf *dmabuf, *ret = NULL; > > + > > + if (*pos) { > > + *pos = 0; > > + return NULL; > > + } > > + /* Look for the first buffer we can obtain a reference to. > > + * The list mutex does not protect a dmabuf's refcount, so it can be > > + * zeroed while we are iterating. Therefore we cannot call get_dma_buf() > > + * since the caller of this program may not already own a reference to > > + * the buffer. > > + */ > > + mutex_lock(&dmabuf_debugfs_list_mutex); > > + list_for_each_entry(dmabuf, &dmabuf_debugfs_list, list_node) { > > + if (file_ref_get(&dmabuf->file->f_ref)) { > > + ret = dmabuf; > > + break; > > + } > > + } > > + mutex_unlock(&dmabuf_debugfs_list_mutex); > > IIUC, the iterator simply traverses elements in a linked list. I feel it is > an overkill to implement a new BPF iterator for it. Like other BPF iterators such as kmem_cache_iter or task_iter. Cgroup_iter iterates trees instead of lists. This is iterating over kernel objects just like the docs say, "A BPF iterator is a type of BPF program that allows users to iterate over specific types of kernel objects". More complicated iteration should not be a requirement here. > Maybe we simply > use debugging tools like crash or drgn for this? The access with > these tools will not be protected by the mutex. But from my personal > experience, this is not a big issue for user space debugging tools. drgn is *way* too slow, and even if it weren't the dependencies for running it aren't available. crash needs debug symbols which also aren't available on user builds. This is not just for manual debugging, it's for reporting memory use in production. Or anything else someone might care to extract like attachment info or refcounts. > Thanks, > Song > > > > + > > + return ret; > > +}

8 months

1
0
0 0

[PATCH 0/4] Replace CONFIG_DMABUF_SYSFS_STATS with BPF

by T.J. Mercier

Until CONFIG_DMABUF_SYSFS_STATS was added [1] it was only possible to perform per-buffer accounting with debugfs which is not suitable for production environments. Eventually we discovered the overhead with per-buffer sysfs file creation/removal was significantly impacting allocation and free times, and exacerbated kernfs lock contention. [2] dma_buf_stats_setup() is responsible for 39% of single-page buffer creation duration, or 74% of single-page dma_buf_export() duration when stressing dmabuf allocations and frees. I prototyped a change from per-buffer to per-exporter statistics with a RCU protected list of exporter allocations that accommodates most (but not all) of our use-cases and avoids almost all of the sysfs overhead. While that adds less overhead than per-buffer sysfs, and less even than the maintenance of the dmabuf debugfs_list, it's still *additional* overhead on top of the debugfs_list and doesn't give us per-buffer info. This series uses the existing dmabuf debugfs_list to implement a BPF dmabuf iterator, which adds no overhead to buffer allocation/free and provides per-buffer info. While the kernel must have CONFIG_DEBUG_FS for the dmabuf_iter to be available, debugfs does not need to be mounted. The BPF program loaded by userspace that extracts per-buffer information gets to define its own interface which avoids the lack of ABI stability with debugfs (even if it were mounted). As this is a replacement for our use of CONFIG_DMABUF_SYSFS_STATS, the last patch is a RFC for removing it from the kernel. Please see my suggestion there regarding the timeline for that. [1] https://lore.kernel.org/linux-media/20201210044400.1080308-1-hridya@google.… [2] https://lore.kernel.org/all/20220516171315.2400578-1-tjmercier@google.com/ T.J. Mercier (4): dma-buf: Rename and expose debugfs symbols bpf: Add dmabuf iterator selftests/bpf: Add test for dmabuf_iter RFC: dma-buf: Remove DMA-BUF statistics .../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 | 40 +--- include/linux/btf_ids.h | 1 + include/linux/dma-buf.h | 6 + kernel/bpf/Makefile | 3 + kernel/bpf/dmabuf_iter.c | 130 +++++++++++ tools/testing/selftests/bpf/config | 1 + .../selftests/bpf/prog_tests/dmabuf_iter.c | 116 ++++++++++ .../testing/selftests/bpf/progs/dmabuf_iter.c | 31 +++ 14 files changed, 299 insertions(+), 311 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 create mode 100644 kernel/bpf/dmabuf_iter.c create mode 100644 tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c create mode 100644 tools/testing/selftests/bpf/progs/dmabuf_iter.c -- 2.49.0.604.gff1f9ca942-goog

8 months

3
8
0 0

Re: [PATCH] dma-buf: heaps: Set allocation orders for larger page sizes

by Christian König

Am 15.04.25 um 19:19 schrieb Juan Yescas: > This change sets the allocation orders for the different page sizes > (4k, 16k, 64k) based on PAGE_SHIFT. Before this change, the orders > for large page sizes were calculated incorrectly, this caused system > heap to allocate from 2% to 4% more memory on 16KiB page size kernels. > > This change was tested on 4k/16k page size kernels. > > Signed-off-by: Juan Yescas <jyescas(a)google.com> > --- > drivers/dma-buf/heaps/system_heap.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c > index 26d5dc89ea16..54674c02dcb4 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -50,8 +50,15 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; > * to match with the sizes often found in IOMMUs. Using order 4 pages instead > * of order 0 pages can significantly improve the performance of many IOMMUs > * by reducing TLB pressure and time spent updating page tables. > + * > + * Note: When the order is 0, the minimum allocation is PAGE_SIZE. The possible > + * page sizes for ARM devices could be 4K, 16K and 64K. > */ > -static const unsigned int orders[] = {8, 4, 0}; > +#define ORDER_1M (20 - PAGE_SHIFT) > +#define ORDER_64K (16 - PAGE_SHIFT) > +#define ORDER_FOR_PAGE_SIZE (0) > +static const unsigned int orders[] = {ORDER_1M, ORDER_64K, ORDER_FOR_PAGE_SIZE}; > +# Good catch, but I think the defines are just overkill. What you should do instead is to subtract page shift when using the array. Apart from that using 1M, 64K and then falling back to 4K just sounds random to me. We have especially pushed back on 64K more than once because it is actually not beneficial in almost all cases. I suggest to fix the code in system_heap_allocate to not over allocate instead and just try the available orders like TTM does. This has proven to be working architecture independent. Regards, Christian. > #define NUM_ORDERS ARRAY_SIZE(orders) > > static struct sg_table *dup_sg_table(struct sg_table *table)

8 months

1
0
0 0

Re: [PATCH v7 2/4] drm/panthor: Add driver IOCTL for setting BO labels

by Steven Price

On 14/04/2025 21:41, Adrián Larumbe wrote: > On 14.04.2025 11:01, Steven Price wrote: >> On 11/04/2025 16:03, Adrián Larumbe wrote: >>> Allow UM to label a BO for which it possesses a DRM handle. >>> >>> Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> >>> Reviewed-by: Liviu Dudau <liviu.dudau(a)arm.com> >>> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> >> >> Reviewed-by: Steven Price <steven.price(a)arm.com> >> >> Although very minor NITs below which you can consider. >> >>> --- >>> drivers/gpu/drm/panthor/panthor_drv.c | 42 ++++++++++++++++++++++++++- >>> drivers/gpu/drm/panthor/panthor_gem.h | 2 ++ >>> include/uapi/drm/panthor_drm.h | 23 +++++++++++++++ >>> 3 files changed, 66 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c >>> index 06fe46e32073..983b24f1236c 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_drv.c >>> +++ b/drivers/gpu/drm/panthor/panthor_drv.c >>> @@ -1331,6 +1331,44 @@ static int panthor_ioctl_vm_get_state(struct drm_device *ddev, void *data, >>> return 0; >>> } >>> >>> +static int panthor_ioctl_bo_set_label(struct drm_device *ddev, void *data, >>> + struct drm_file *file) >>> +{ >>> + struct drm_panthor_bo_set_label *args = data; >>> + struct drm_gem_object *obj; >>> + const char *label; >>> + int ret = 0; >>> + >>> + obj = drm_gem_object_lookup(file, args->handle); >>> + if (!obj) >>> + return -ENOENT; >>> + >>> + if (args->size && args->label) { >>> + if (args->size > PANTHOR_BO_LABEL_MAXLEN) { >>> + ret = -E2BIG; >>> + goto err_label; >>> + } >>> + >>> + label = strndup_user(u64_to_user_ptr(args->label), args->size); >>> + if (IS_ERR(label)) { >>> + ret = PTR_ERR(label); >>> + goto err_label; >>> + } >>> + } else if (args->size && !args->label) { >>> + ret = -EINVAL; >>> + goto err_label; >>> + } else { >>> + label = NULL; >>> + } >>> + >>> + panthor_gem_bo_set_label(obj, label); >>> + >>> +err_label: >>> + drm_gem_object_put(obj); >>> + >>> + return ret; >>> +} >>> + >>> static int >>> panthor_open(struct drm_device *ddev, struct drm_file *file) >>> { >>> @@ -1400,6 +1438,7 @@ static const struct drm_ioctl_desc panthor_drm_driver_ioctls[] = { >>> PANTHOR_IOCTL(TILER_HEAP_CREATE, tiler_heap_create, DRM_RENDER_ALLOW), >>> PANTHOR_IOCTL(TILER_HEAP_DESTROY, tiler_heap_destroy, DRM_RENDER_ALLOW), >>> PANTHOR_IOCTL(GROUP_SUBMIT, group_submit, DRM_RENDER_ALLOW), >>> + PANTHOR_IOCTL(BO_SET_LABEL, bo_set_label, DRM_RENDER_ALLOW), >>> }; >>> >>> static int panthor_mmap(struct file *filp, struct vm_area_struct *vma) >>> @@ -1509,6 +1548,7 @@ static void panthor_debugfs_init(struct drm_minor *minor) >>> * - 1.2 - adds DEV_QUERY_GROUP_PRIORITIES_INFO query >>> * - adds PANTHOR_GROUP_PRIORITY_REALTIME priority >>> * - 1.3 - adds DRM_PANTHOR_GROUP_STATE_INNOCENT flag >>> + * - 1.4 - adds DRM_IOCTL_PANTHOR_BO_SET_LABEL ioctl >>> */ >>> static const struct drm_driver panthor_drm_driver = { >>> .driver_features = DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ | >>> @@ -1522,7 +1562,7 @@ static const struct drm_driver panthor_drm_driver = { >>> .name = "panthor", >>> .desc = "Panthor DRM driver", >>> .major = 1, >>> - .minor = 3, >>> + .minor = 4, >>> >>> .gem_create_object = panthor_gem_create_object, >>> .gem_prime_import_sg_table = drm_gem_shmem_prime_import_sg_table, >>> diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h >>> index af0d77338860..beba066b4974 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_gem.h >>> +++ b/drivers/gpu/drm/panthor/panthor_gem.h >>> @@ -13,6 +13,8 @@ >>> >>> struct panthor_vm; >>> >>> +#define PANTHOR_BO_LABEL_MAXLEN PAGE_SIZE >>> + >>> /** >>> * struct panthor_gem_object - Driver specific GEM object. >>> */ >>> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h >>> index 97e2c4510e69..12b1994499a9 100644 >>> --- a/include/uapi/drm/panthor_drm.h >>> +++ b/include/uapi/drm/panthor_drm.h >>> @@ -127,6 +127,9 @@ enum drm_panthor_ioctl_id { >>> >>> /** @DRM_PANTHOR_TILER_HEAP_DESTROY: Destroy a tiler heap. */ >>> DRM_PANTHOR_TILER_HEAP_DESTROY, >>> + >>> + /** @DRM_PANTHOR_BO_SET_LABEL: Label a BO. */ >>> + DRM_PANTHOR_BO_SET_LABEL, >>> }; >>> >>> /** >>> @@ -977,6 +980,24 @@ struct drm_panthor_tiler_heap_destroy { >>> __u32 pad; >>> }; >>> >>> +/** >>> + * struct drm_panthor_bo_set_label - Arguments passed to DRM_IOCTL_PANTHOR_BO_SET_LABEL >>> + */ >>> +struct drm_panthor_bo_set_label { >>> + /** @handle: Handle of the buffer object to label. */ >>> + __u32 handle; >>> + >>> + /** >>> + * @size: Length of the label, including the NULL terminator. >>> + * >>> + * Cannot be greater than the OS page size. >>> + */ >>> + __u32 size; >>> + >>> + /** @label: User pointer to a NULL-terminated string */ >>> + __u64 label; >>> +}; >> >> First very minor NIT: >> * NULL is a pointer, i.e. (void*)0 >> * NUL is the ASCII code point '\0'. >> So it's a NUL-terminated string. > > Fixed > >> Second NIT: We don't actually need 'size' - since the string is >> NUL-terminated we can just strndup_user(__user_pointer__, PAGE_SIZE). >> As things stand we validate that strlen(label) < size <= PAGE_SIZE - >> which is a little odd (user space might as well just pass PAGE_SIZE >> rather than calculate the actual length). > > The snag I see in this approach is that the only way to make sure > strlen(label) + 1 <= PAGE_SIZE would be doing something like > > label = strndup_user(u64_to_user_ptr(args->label), args->size); > if (strlen(label) + 1 <= PAGE_SIZE) { > kfree(label) > return -E2BIG; > } You can just do strndup_user(u64_to_user_ptr(args->label), PAGE_SIZE) If you look at the kernel's implementation it handles an overly long string by returning an error: > length = strnlen_user(s, n); > > if (!length) > return ERR_PTR(-EFAULT); > > if (length > n) > return ERR_PTR(-EINVAL); > > p = memdup_user(s, length); So there's no need to call strlen() on the result. > In the meantime, we've duplicated the string and traversed a whole page > of bytes, all to be discarded at once. > > In this case, I think it's alright to expect some cooperation from UM > in supplying the actual size, although I'm really not an expert in > designing elegant uAPIs, so if you think this looks very odd I'd be > glad to replace it with. > > Actually, as I was writing this, I realised that strndup_user() calls > strnlen_user(), which is publicly available for other drivers, so > I might check the length first, and if it falls within bounds, do > the actual user stringdup. Again, no need (and strnlen_user() has a comment basically saying "don't call this"). strndup_user() has all the magic we need here. As I say this is just a 'nit' - so no big deal. But I don't really see the point of the size in the uAPI. Take a look at dma_buf_set_name() for an example which sets the name on a dma_buf (and doesn't take a size argument) - although that wasn't an example of good uAPI design as the type in the ioctl was botched ;( Thanks, Steve > I shall also mention the size bound on the uAPI for the 'label' pointer. > >> Thanks, >> Steve >> >> + >> /** >> * DRM_IOCTL_PANTHOR() - Build a Panthor IOCTL number >> * @__access: Access type. Must be R, W or RW. >> @@ -1019,6 +1040,8 @@ enum { >> DRM_IOCTL_PANTHOR(WR, TILER_HEAP_CREATE, tiler_heap_create), >> DRM_IOCTL_PANTHOR_TILER_HEAP_DESTROY = >> DRM_IOCTL_PANTHOR(WR, TILER_HEAP_DESTROY, tiler_heap_destroy), >> + DRM_IOCTL_PANTHOR_BO_SET_LABEL = >> + DRM_IOCTL_PANTHOR(WR, BO_SET_LABEL, bo_set_label), >> }; >> >> #if defined(__cplusplus) > > > Adrian Larumbe

8 months

1
0
0 0

Re: [PATCH v7 1/4] drm/panthor: Introduce BO labeling

by Steven Price

On 14/04/2025 20:43, Adrián Larumbe wrote: > Hi Steven, > > On 14.04.2025 10:50, Steven Price wrote: >> Hi Adrián, >> >> On 11/04/2025 16:03, Adrián Larumbe wrote: >>> Add a new character string Panthor BO field, and a function that allows >>> setting it from within the driver. >>> >>> Driver takes care of freeing the string when it's replaced or no longer >>> needed at object destruction time, but allocating it is the responsibility >>> of callers. >>> >>> Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> >>> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> >>> --- >>> drivers/gpu/drm/panthor/panthor_gem.c | 39 +++++++++++++++++++++++++++ >>> drivers/gpu/drm/panthor/panthor_gem.h | 17 ++++++++++++ >>> 2 files changed, 56 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c >>> index 8244a4e6c2a2..af0ac17f357f 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_gem.c >>> +++ b/drivers/gpu/drm/panthor/panthor_gem.c >>> @@ -2,6 +2,7 @@ >>> /* Copyright 2019 Linaro, Ltd, Rob Herring <robh(a)kernel.org> */ >>> /* Copyright 2023 Collabora ltd. */ >>> >>> +#include <linux/cleanup.h> >>> #include <linux/dma-buf.h> >>> #include <linux/dma-mapping.h> >>> #include <linux/err.h> >>> @@ -18,6 +19,14 @@ static void panthor_gem_free_object(struct drm_gem_object *obj) >>> struct panthor_gem_object *bo = to_panthor_bo(obj); >>> struct drm_gem_object *vm_root_gem = bo->exclusive_vm_root_gem; >>> >>> + /* >>> + * Label might have been allocated with kstrdup_const(), >>> + * we need to take that into account when freeing the memory >>> + */ >>> + kfree_const(bo->label.str); >>> + >>> + mutex_destroy(&bo->label.lock); >>> + >>> drm_gem_free_mmap_offset(&bo->base.base); >>> mutex_destroy(&bo->gpuva_list_lock); >>> drm_gem_shmem_free(&bo->base); >>> @@ -196,6 +205,7 @@ struct drm_gem_object *panthor_gem_create_object(struct drm_device *ddev, size_t >>> obj->base.map_wc = !ptdev->coherent; >>> mutex_init(&obj->gpuva_list_lock); >>> drm_gem_gpuva_set_lock(&obj->base.base, &obj->gpuva_list_lock); >>> + mutex_init(&obj->label.lock); >>> >>> return &obj->base.base; >>> } >>> @@ -247,3 +257,32 @@ panthor_gem_create_with_handle(struct drm_file *file, >>> >>> return ret; >>> } >>> + >>> +void >>> +panthor_gem_bo_set_label(struct drm_gem_object *obj, const char *label) >>> +{ >>> + struct panthor_gem_object *bo = to_panthor_bo(obj); >>> + const char *old_label; >>> + >>> + scoped_guard(mutex, &bo->label.lock) { >>> + old_label = bo->label.str; >>> + bo->label.str = label; >>> + } >>> + >>> + kfree(old_label); >> >> Shouldn't this be kfree_const()? I suspect as things stand we can't >> trigger this bug but it's inconsistent. > > This could only be called either from the set_label() ioctl, in which case > old_label could be NULL or a pointer to a string obtained from strdup(); or from > panthor_gem_kernel_bo_set_label(). In the latter case, it could only ever be > NULL, since we don't reassign kernel BO labels, so it'd be safe too. Yeah I thought it probably doesn't cause problems now, but it's a foot gun for the future. > However I do agree that it's not consistent, and then in the future perhaps > relabelling kernel BO's might be justified, so I'll change it to kfree_const(). Thanks! >>> +} >>> + >>> +void >>> +panthor_gem_kernel_bo_set_label(struct panthor_kernel_bo *bo, const char *label) >>> +{ >>> + const char *str; >>> + >>> + str = kstrdup_const(label, GFP_KERNEL); >>> + if (!str) { >> >> In the next patch you permit user space to clear the label >> (args->size==0) which means label==NULL and AFAICT kstrdup_const() will >> return NULL in this case triggering this warning. > > Kernel and UM-exposed BO's should never experience cross-labelling, so in theory > this scenario ought to be impossible. The only way panthor_gem_kernel_bo_set_label() > might take NULL in the 'label' argument is that someone called panthor_kernel_bo_create() > with NULL for its name 'argument'. You're absolutely correct - I somehow got confused between the kernel and user paths. It's the user path above which needs to handle NULL (and does). > I think as a defensive check, I could do something as follows > > void > panthor_gem_kernel_bo_set_label(struct panthor_kernel_bo *bo, const char *label) > { > const char *str; > > /* We should never attempt labelling a UM-exposed GEM object */ > if (drm_WARN_ON(bo->obj->dev, &bo->obj->handle_count > 0)) > return; > > if (!label) > return; > > [...] > } I'm happy for you to do nothing here - that was my mistake getting the two functions muddled. Sorry for the noise. I'm equally happy for the defensive checks above. Steve >> Thanks, >> Steve >> >>> + /* Failing to allocate memory for a label isn't a fatal condition */ >>> + drm_warn(bo->obj->dev, "Not enough memory to allocate BO label"); >>> + return; >>> + } >>> + >>> + panthor_gem_bo_set_label(bo->obj, str); >>> +} >>> diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h >>> index 1a363bb814f4..af0d77338860 100644 >>> --- a/drivers/gpu/drm/panthor/panthor_gem.h >>> +++ b/drivers/gpu/drm/panthor/panthor_gem.h >>> @@ -46,6 +46,20 @@ struct panthor_gem_object { >>> >>> /** @flags: Combination of drm_panthor_bo_flags flags. */ >>> u32 flags; >>> + >>> + /** >>> + * @label: BO tagging fields. The label can be assigned within the >>> + * driver itself or through a specific IOCTL. >>> + */ >>> + struct { >>> + /** >>> + * @label.str: Pointer to NULL-terminated string, >>> + */ >>> + const char *str; >>> + >>> + /** @lock.str: Protects access to the @label.str field. */ >>> + struct mutex lock; >>> + } label; >>> }; >>> >>> /** >>> @@ -91,6 +105,9 @@ panthor_gem_create_with_handle(struct drm_file *file, >>> struct panthor_vm *exclusive_vm, >>> u64 *size, u32 flags, uint32_t *handle); >>> >>> +void panthor_gem_bo_set_label(struct drm_gem_object *obj, const char *label); >>> +void panthor_gem_kernel_bo_set_label(struct panthor_kernel_bo *bo, const char *label); >>> + >>> static inline u64 >>> panthor_kernel_bo_gpuva(struct panthor_kernel_bo *bo) >>> { > > Adrian Larumbe

8 months

1
0
0 0

[PATCH v3] drm/gem: Internally test import_attach for imported objects

by Thomas Zimmermann

Test struct drm_gem_object.import_attach to detect imported objects. During object clenanup, the dma_buf field might be NULL. Testing it in an object's free callback then incorrectly does a cleanup as for native objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that clears the dma_buf field in drm_gem_object_exported_dma_buf_free(). v3: - only test for import_attach (Boris) v2: - use import_attach.dmabuf instead of dma_buf (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Reported-by: Andy Yan <andyshrk(a)163.com> Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andysh… Tested-by: Andy Yan <andyshrk(a)163.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Anusha Srivatsa <asrivats(a)redhat.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)gmail.com> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- include/drm/drm_gem.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h index 9b71f7a9f3f8..a3133a08267c 100644 --- a/include/drm/drm_gem.h +++ b/include/drm/drm_gem.h @@ -588,8 +588,7 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje */ static inline bool drm_gem_is_imported(const struct drm_gem_object *obj) { - /* The dma-buf's priv field points to the original GEM object. */ - return obj->dma_buf && (obj->dma_buf->priv != obj); + return !!obj->import_attach; } #ifdef CONFIG_LOCKDEP -- 2.49.0

8 months

1
0
0 0

Re: [PATCH] dma-buf: heaps: Set allocation orders for larger page sizes

by T.J. Mercier

On Tue, Apr 15, 2025 at 10:20 AM Juan Yescas <jyescas(a)google.com> wrote: > > This change sets the allocation orders for the different page sizes > (4k, 16k, 64k) based on PAGE_SHIFT. Before this change, the orders > for large page sizes were calculated incorrectly, this caused system > heap to allocate from 2% to 4% more memory on 16KiB page size kernels. > > This change was tested on 4k/16k page size kernels. > > Signed-off-by: Juan Yescas <jyescas(a)google.com> I think "dma-buf: system_heap:" would be better for the subject since this is specific to the system heap. Would you mind cleaning up the extra space on line 321 too? @@ -318,7 +318,7 @@ static struct page *alloc_largest_available(unsigned long size, int i; for (i = 0; i < NUM_ORDERS; i++) { - if (size < (PAGE_SIZE << orders[i])) + if (size < (PAGE_SIZE << orders[i])) With that, Reviewed-by: T.J. Mercier <tjmercier(a)google.com> Fixes: d963ab0f15fb ("dma-buf: system_heap: Allocate higher order pages if available") is also probably a good idea. > --- > drivers/dma-buf/heaps/system_heap.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c > index 26d5dc89ea16..54674c02dcb4 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -50,8 +50,15 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; > * to match with the sizes often found in IOMMUs. Using order 4 pages instead > * of order 0 pages can significantly improve the performance of many IOMMUs > * by reducing TLB pressure and time spent updating page tables. > + * > + * Note: When the order is 0, the minimum allocation is PAGE_SIZE. The possible > + * page sizes for ARM devices could be 4K, 16K and 64K. > */ > -static const unsigned int orders[] = {8, 4, 0}; > +#define ORDER_1M (20 - PAGE_SHIFT) > +#define ORDER_64K (16 - PAGE_SHIFT) > +#define ORDER_FOR_PAGE_SIZE (0) > +static const unsigned int orders[] = {ORDER_1M, ORDER_64K, ORDER_FOR_PAGE_SIZE}; > + > #define NUM_ORDERS ARRAY_SIZE(orders) > > static struct sg_table *dup_sg_table(struct sg_table *table) > -- > 2.49.0.604.gff1f9ca942-goog >

8 months

1
0
0 0

Re: [PATCH] dma-buf: heaps: Set allocation orders for larger page sizes

by John Stultz

On Tue, Apr 15, 2025 at 10:20 AM Juan Yescas <jyescas(a)google.com> wrote: > > This change sets the allocation orders for the different page sizes > (4k, 16k, 64k) based on PAGE_SHIFT. Before this change, the orders > for large page sizes were calculated incorrectly, this caused system > heap to allocate from 2% to 4% more memory on 16KiB page size kernels. > > This change was tested on 4k/16k page size kernels. > > Signed-off-by: Juan Yescas <jyescas(a)google.com> Seems reasonable to me. Acked-by: John Stultz <jstultz(a)google.com> thanks -john

8 months

1
0
0 0

Re: [PATCH v2] drm/gem: Internally test import_attach for imported objects

by Thomas Zimmermann

Hi Am 15.04.25 um 16:19 schrieb Boris Brezillon: > On Tue, 15 Apr 2025 16:02:20 +0200 > Thomas Zimmermann <tzimmermann(a)suse.de> wrote: > >> Test struct drm_gem_object.import_attach.dmabuf to detect imported >> objects. Warn if the stored state is inconsistent. >> >> During object clenaup, the dma_buf field might be NULL. Testing it in >> an object's free callback then incorrectly does a cleanup as for native >> objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that >> clears the dma_buf field in drm_gem_object_exported_dma_buf_free(). >> >> v2: >> - use import_attach.dmabuf instead of dma_buf (Christian) >> >> Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> >> Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") >> Reported-by: Andy Yan <andyshrk(a)163.com> >> Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andysh… >> Tested-by: Andy Yan <andyshrk(a)163.com> >> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> >> Cc: Anusha Srivatsa <asrivats(a)redhat.com> >> Cc: Christian König <christian.koenig(a)amd.com> >> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> >> Cc: Maxime Ripard <mripard(a)kernel.org> >> Cc: David Airlie <airlied(a)gmail.com> >> Cc: Simona Vetter <simona(a)ffwll.ch> >> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> >> Cc: "Christian König" <christian.koenig(a)amd.com> >> Cc: dri-devel(a)lists.freedesktop.org >> Cc: linux-media(a)vger.kernel.org >> Cc: linaro-mm-sig(a)lists.linaro.org >> --- >> include/drm/drm_gem.h | 26 ++++++++++++++++++++++++-- >> 1 file changed, 24 insertions(+), 2 deletions(-) >> >> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h >> index 9b71f7a9f3f8..464b9c7feec0 100644 >> --- a/include/drm/drm_gem.h >> +++ b/include/drm/drm_gem.h >> @@ -579,6 +579,21 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje >> return (obj->handle_count > 1) || obj->dma_buf; >> } >> >> +/** >> + * drm_gem_owns_dma_buf() - Tests if GEM object backs a DMA-buffer object >> + * @obj: the GEM object >> + * @obj: the DMA buffer >> + * >> + * Returns: >> + * True if the DMA buffer refers to the GEM object's buffer. >> + */ >> +static inline bool drm_gem_owns_dma_buf(const struct drm_gem_object *obj, >> + const struct dma_buf *dma_buf) >> +{ >> + /* The dma-buf's priv field points to the original GEM object. */ >> + return dma_buf->priv == obj; >> +} >> + >> /** >> * drm_gem_is_imported() - Tests if GEM object's buffer has been imported >> * @obj: the GEM object >> @@ -588,8 +603,15 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje >> */ >> static inline bool drm_gem_is_imported(const struct drm_gem_object *obj) >> { >> - /* The dma-buf's priv field points to the original GEM object. */ >> - return obj->dma_buf && (obj->dma_buf->priv != obj); >> + const struct dma_buf *dma_buf = NULL; >> + >> + if (!obj->import_attach) >> + return false; >> + >> + dma_buf = obj->import_attach->dmabuf; >> + >> + /* Warn if we somehow reimported our own buffer. */ >> + return !drm_WARN_ON_ONCE(obj->dev, !dma_buf || drm_gem_owns_dma_buf(obj, dma_buf)); > I'm honestly not sure I see the point of checking > obj->import_attach->dmabuf. If obj->import_attach != NULL, we're sure > it's a foreign buffer already, otherwise we would get the original GEM > object which has ->import_attach=NULL. So why not go for a simple > > return obj->import_attach != NULL; > > check, and extend the check when you get to implement imports without > import attachments (not sure what those would look like BTW). I have no strong opinion. I just found it confusing to rely on import_attach when the dma_buf is what we originally imported. Best regards Thomas -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

8 months

1
0
0 0

[PATCH] drm/gem: Internally test import_attach for imported objects

by Thomas Zimmermann

Test struct drm_gem_object.import_attach to detect imported objects during cleanup. At that point, the imported DMA buffer might have already been released and the dma_buf field is NULL. The object's free callback then does a cleanup as for native objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that eventually clear the dma_buf field in drm_gem_object_exported_dma_buf_free(). Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Reported-by: Andy Yan <andyshrk(a)163.com> Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andysh… Tested-by: Andy Yan <andyshrk(a)163.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Anusha Srivatsa <asrivats(a)redhat.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)gmail.com> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- include/drm/drm_gem.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h index 9b71f7a9f3f8..f09b8afcf86d 100644 --- a/include/drm/drm_gem.h +++ b/include/drm/drm_gem.h @@ -589,7 +589,13 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje static inline bool drm_gem_is_imported(const struct drm_gem_object *obj) { /* The dma-buf's priv field points to the original GEM object. */ - return obj->dma_buf && (obj->dma_buf->priv != obj); + return (obj->dma_buf && (obj->dma_buf->priv != obj)) || + /* + * TODO: During object release, the dma-buf might already + * be gone. For now keep testing import_attach, but + * this should be removed at some point. + */ + obj->import_attach; } #ifdef CONFIG_LOCKDEP -- 2.49.0

8 months

2
7
0 0

[PATCH v2] drm/gem: Internally test import_attach for imported objects

by Thomas Zimmermann

Test struct drm_gem_object.import_attach.dmabuf to detect imported objects. Warn if the stored state is inconsistent. During object clenaup, the dma_buf field might be NULL. Testing it in an object's free callback then incorrectly does a cleanup as for native objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that clears the dma_buf field in drm_gem_object_exported_dma_buf_free(). v2: - use import_attach.dmabuf instead of dma_buf (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Reported-by: Andy Yan <andyshrk(a)163.com> Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andysh… Tested-by: Andy Yan <andyshrk(a)163.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Anusha Srivatsa <asrivats(a)redhat.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)gmail.com> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- include/drm/drm_gem.h | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h index 9b71f7a9f3f8..464b9c7feec0 100644 --- a/include/drm/drm_gem.h +++ b/include/drm/drm_gem.h @@ -579,6 +579,21 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje return (obj->handle_count > 1) || obj->dma_buf; } +/** + * drm_gem_owns_dma_buf() - Tests if GEM object backs a DMA-buffer object + * @obj: the GEM object + * @obj: the DMA buffer + * + * Returns: + * True if the DMA buffer refers to the GEM object's buffer. + */ +static inline bool drm_gem_owns_dma_buf(const struct drm_gem_object *obj, + const struct dma_buf *dma_buf) +{ + /* The dma-buf's priv field points to the original GEM object. */ + return dma_buf->priv == obj; +} + /** * drm_gem_is_imported() - Tests if GEM object's buffer has been imported * @obj: the GEM object @@ -588,8 +603,15 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje */ static inline bool drm_gem_is_imported(const struct drm_gem_object *obj) { - /* The dma-buf's priv field points to the original GEM object. */ - return obj->dma_buf && (obj->dma_buf->priv != obj); + const struct dma_buf *dma_buf = NULL; + + if (!obj->import_attach) + return false; + + dma_buf = obj->import_attach->dmabuf; + + /* Warn if we somehow reimported our own buffer. */ + return !drm_WARN_ON_ONCE(obj->dev, !dma_buf || drm_gem_owns_dma_buf(obj, dma_buf)); } #ifdef CONFIG_LOCKDEP -- 2.49.0

8 months

1
0
0 0

Re: [PATCH] drm/gem: Internally test import_attach for imported objects

by Christian König

Am 15.04.25 um 15:10 schrieb Simona Vetter: >> This is for devices who only want to do a vmap of the buffer, isn't it? > ... it's for the vmap only case, where you might not even have a struct > device. Or definitely not a reasonable one, like maybe a faux_bus device > or some device on a bus that really doesn't do dma (e.g. spi or i2c), and > where hence dma_buf_map_attachment is just something you never ever want > to do. Even in that case I would still suggest to at least create an attachment to let the exporter know that somebody is doing something with it's buffer. That is also important for move notification since you can't do those without an attachment. BTW: What is keeping a vmap alive after dropping the reservation lock? There is no pinning whatsoever as far as I can see. > I think we might want to transform obj->import_attach into a union or > tagged pointer or something like that, which can cover both cases. And > maybe a drm_gem_bo_imported_dma_buf() helper that gives you the dma_buf no > matter what if it's imported, or NULL if it's allocated on that > drm_device? Yeah, I had the same idea before as well. Just didn't know if that was something worth looking into. Regards, Christian. > > Cheers, Sima

8 months

1
0
0 0

Re: [PATCH v2 2/2] drm/nouveau: nouveau_fence: Standardize list iterations

by Christian König

Am 15.04.25 um 14:19 schrieb Philipp Stanner: > nouveau_fence.c iterates over lists in a non-canonical way. Since the > operations done are just basic for-each-loops, they should be written in > the standard form. > > Use for_each_safe() instead of the custom loop iterations. > > Signed-off-by: Philipp Stanner <phasta(a)kernel.org> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > index 6ded8c2b6d3b..60d961b43488 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > @@ -84,11 +84,12 @@ void > nouveau_fence_context_kill(struct nouveau_fence_chan *fctx, int error) > { > struct nouveau_fence *fence; > + struct list_head *pos, *tmp; > unsigned long flags; > > spin_lock_irqsave(&fctx->lock, flags); > - while (!list_empty(&fctx->pending)) { > - fence = list_entry(fctx->pending.next, typeof(*fence), head); > + list_for_each_safe(pos, tmp, &fctx->pending) { > + fence = list_entry(pos, struct nouveau_fence, head); > > if (error && !dma_fence_is_signaled_locked(&fence->base)) > dma_fence_set_error(&fence->base, error); > @@ -131,11 +132,12 @@ static int > nouveau_fence_update(struct nouveau_channel *chan, struct nouveau_fence_chan *fctx) > { > struct nouveau_fence *fence; > + struct list_head *pos, *tmp; > int drop = 0; > u32 seq = fctx->read(chan); > > - while (!list_empty(&fctx->pending)) { > - fence = list_entry(fctx->pending.next, typeof(*fence), head); > + list_for_each_safe(pos, tmp, &fctx->pending) { > + fence = list_entry(pos, struct nouveau_fence, head); > > if ((int)(seq - fence->base.seqno) < 0) > break;

8 months

1
0
0 0

Re: [PATCH v7 2/4] drm/panthor: Add driver IOCTL for setting BO labels

by Daniel Stone

Hi, On Fri, 11 Apr 2025 at 16:05, Adrián Larumbe <adrian.larumbe(a)collabora.com> wrote: > +#define PANTHOR_BO_LABEL_MAXLEN PAGE_SIZE PAGE_SIZE can change between kernel builds with a config setting. If the thinking here is '4KiB is big enough' (which I agree with), then just define it to 4096. Cheers, Daniel

8 months

1
0
0 0

Re: [PATCH 1/3] drm/nouveau: Prevent signaled fences in pending list

by Christian König

Am 14.04.25 um 16:27 schrieb Danilo Krummrich: > On Mon, Apr 14, 2025 at 10:54:25AM +0200, Philipp Stanner wrote: >> @Danilo: >> We have now 2 possible solutions for the firing WARN_ON floating. >> >> Version A (Christian) >> Check in nouveau_fence_context_kill() whether a fence is already >> signaled before setting an error. >> >> Version B (Me) >> This patch series here. Make sure that in Nouveau, only >> nouveau_fence_signal() signals fences. >> >> >> Both should do the trick. Please share a maintainer-preference so I can >> move on here. > Thanks for working on this Philipp. > > If you don't want to rework things entirely, A seems to be superior, since it > also catches the case when someone else would call dma_fence_is_signaled() on a > nouveau fence (which could happen at any time). This doesn't seem to be caught > by B, right? Correct, yes. I would also keep it as simple as possible for backporting this bug fix. On the other hand a rework is certainly appropriate including both nouveau as well as the DMA-fence calling rules. Especially that the DMA-fence framework calls the signaled callback with inconsistent locking is something we should fix. Regards, Christian.

8 months

1
0
0 0

Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

by Andrew Davis

On 4/14/25 2:21 PM, Thomas Petazzoni wrote: > Hello Andrew, > > On Mon, 14 Apr 2025 12:08:44 -0500 > Andrew Davis <afd(a)ti.com> wrote: > >> "UIO is a broken legacy mess, so let's add more broken things >> to it as broken + broken => still broken, so no harm done", am I >> getting that right? > > Who says UIO is a "broken legacy mess"? Only you says so. I don't see > any indication anywhere in the kernel tree suggesting that UIO is > considered a broken legacy mess. > I'm not saying that*, I'm pointing out your argument is that even though what you are trying to do is broken and unsafe, it is okay to do because it isn't any "more "broken and unsafe" than UIO already is." *It is, but that is an argument to have outside of this thread :) > Keep in mind that when you're running code as root, you can load a > kernel module, which can do anything on the system security-wise. So > letting UIO expose MMIO registers of devices to userspace applications > running as root is not any worse than that. > You can take your computer out back and shoot it too, but we shouldn't encourage that either :) According to the original docs, UIO was created to support "industrial I/O cards", think old one-off custom ISA cards by vendors that had no intention of ever writing a proper driver and just wanted to poke registers and wait on an IRQ. IMHO we shouldn't be encouraging that, and trying to modernize UIO does just that. It gives the impression that is how drivers should still be written. If you setup your FPGA card to go blink an LED, sure UIO driver it is, anything more complex, then writing a proper driver is the way to go. >> If your FPGA IP can do DMA then you should not be using UIO in >> the first place, see UIO docs: >> >>> Please note that UIO is not an universal driver interface. Devices that >>> are already handled well by other kernel subsystems (like networking or >>> serial or USB) are no candidates for an UIO driver. >> >> The DMA subsystem already handles DMA devices, so write a DMA driver. > > My FPGA IP block is not a DMA controller that would fit the dmaengine > kernel subsystem. It's a weird custom device that doesn't fit in any > existing subsystem, and that happens to do "peripheral DMA" (i.e the IP > block is DMA-capable itself, without relying on a separate DMA > controller). So this (very valid) recommendation from the UIO > documentation doesn't apply to my device. Peripheral DMA is the much more common case, nothing new here. Could you give a hint as to what this device does that doesn't fit *any* current subsystem? Or are we talking a hypothetical device (which for the sake of argument is a valid thing to say, I'm sure with an FPGA card I could make something that doesn't fit any current framework too). Just want to know if you are trying to solve a specific issue or a generic issue here. Andrew > > Best regards, > > Thomas

8 months

1
0
0 0

Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

by Andrew Davis

On 4/14/25 6:48 AM, Thomas Petazzoni wrote: > Hello Christoph, > > On Mon, 14 Apr 2025 04:24:21 -0700 > Christoph Hellwig <hch(a)infradead.org> wrote: > >> On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote: >>> What this patch series is about is to add new user-space interface to >>> extend the existing UIO subsystem. >> >> Which as I explained to you is fundamentally broken and unsafe. If you >> need to do DMA from userspae you need to use vfio/iommufd. > > I'm still unclear as to why it is more "broken and unsafe" than UIO > already is. As I already replied in this thread: UIO allows to remap > MMIO registers into a user-space application, which can then do > whatever it wants with the IP block behind those MMIO registers. If > this IP block supports DMA, it already means that _today_ with the > current UIO subsystem as it is, the user-space application can program > a DMA transfer to read/write to any location in memory. > > Therefore, providing a way to cleanly allocate DMA buffers and get > their physical address will not make things any better or worse in > terms of safety. > > The fact that it is reasonably safe is solely based on access control > to the UIO device, done using usual Unix permissions, and that is > already the case today. > >>> I am not sure how this can work in our use-case. We have a very simple >>> set of IP blocks implemented in a FPGA, some of those IP blocks are >>> able to perform DMA operations. The register of those IP blocks are >>> mapped into a user-space application using the existing, accepted >>> upstream, UIO subsystem. Some of those registers allow to program DMA >>> transfers. So far, we can do all what we need, except program those DMA >>> transfers. Lots of people are having the same issue, and zillions of >>> ugly out-of-tree solutions flourish all over, and we're trying to see >>> if we can constructively find a solution that would be acceptable >>> upstream to resolve this use-case. Our platform is an old PowerPC with >>> no IOMMU. >> >> Then your driver design can't work and you need to replace it with a >> proper in-kernel driver. > > See above: your point is moot because providing capabilities to > allocate a buffer and get its physical address so that a UIO-based > user-space application can do DMA transfer does not make things any > more unsafe than they already are. > "UIO is a broken legacy mess, so let's add more broken things to it as broken + broken => still broken, so no harm done", am I getting that right? If your FPGA IP can do DMA then you should not be using UIO in the first place, see UIO docs: > Please note that UIO is not an universal driver interface. Devices that > are already handled well by other kernel subsystems (like networking or > serial or USB) are no candidates for an UIO driver. The DMA subsystem already handles DMA devices, so write a DMA driver. Andrew > Best regards, > > Thomas

8 months

1
0
0 0

Re: [PATCH v7 3/4] drm/panthor: Label all kernel BO's

by kernel test robot

Hi Adrián, kernel test robot noticed the following build warnings: [auto build test WARNING on linus/master] [also build test WARNING on v6.15-rc2 next-20250414] [cannot apply to drm-misc/drm-misc-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Adri-n-Larumbe/drm-panthor-I… base: linus/master patch link: https://lore.kernel.org/r/20250411150357.3308921-4-adrian.larumbe%40collabo… patch subject: [PATCH v7 3/4] drm/panthor: Label all kernel BO's config: i386-buildonly-randconfig-006-20250414 (https://download.01.org/0day-ci/archive/20250414/202504142148.NBAyzLuE-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250414/202504142148.NBAyzLuE-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202504142148.NBAyzLuE-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/gpu/drm/panthor/panthor_gem.c:86: warning: Function parameter or struct member 'name' not described in 'panthor_kernel_bo_create' vim +86 drivers/gpu/drm/panthor/panthor_gem.c 8a1cc07578bf42 Boris Brezillon 2024-02-29 67 8a1cc07578bf42 Boris Brezillon 2024-02-29 68 /** 8a1cc07578bf42 Boris Brezillon 2024-02-29 69 * panthor_kernel_bo_create() - Create and map a GEM object to a VM 8a1cc07578bf42 Boris Brezillon 2024-02-29 70 * @ptdev: Device. 8a1cc07578bf42 Boris Brezillon 2024-02-29 71 * @vm: VM to map the GEM to. If NULL, the kernel object is not GPU mapped. 8a1cc07578bf42 Boris Brezillon 2024-02-29 72 * @size: Size of the buffer object. 8a1cc07578bf42 Boris Brezillon 2024-02-29 73 * @bo_flags: Combination of drm_panthor_bo_flags flags. 8a1cc07578bf42 Boris Brezillon 2024-02-29 74 * @vm_map_flags: Combination of drm_panthor_vm_bind_op_flags (only those 8a1cc07578bf42 Boris Brezillon 2024-02-29 75 * that are related to map operations). 8a1cc07578bf42 Boris Brezillon 2024-02-29 76 * @gpu_va: GPU address assigned when mapping to the VM. 8a1cc07578bf42 Boris Brezillon 2024-02-29 77 * If gpu_va == PANTHOR_VM_KERNEL_AUTO_VA, the virtual address will be 8a1cc07578bf42 Boris Brezillon 2024-02-29 78 * automatically allocated. 8a1cc07578bf42 Boris Brezillon 2024-02-29 79 * 8a1cc07578bf42 Boris Brezillon 2024-02-29 80 * Return: A valid pointer in case of success, an ERR_PTR() otherwise. 8a1cc07578bf42 Boris Brezillon 2024-02-29 81 */ 8a1cc07578bf42 Boris Brezillon 2024-02-29 82 struct panthor_kernel_bo * 8a1cc07578bf42 Boris Brezillon 2024-02-29 83 panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, 8a1cc07578bf42 Boris Brezillon 2024-02-29 84 size_t size, u32 bo_flags, u32 vm_map_flags, f48f05d54f7696 Adrián Larumbe 2025-04-11 85 u64 gpu_va, const char *name) 8a1cc07578bf42 Boris Brezillon 2024-02-29 @86 { 8a1cc07578bf42 Boris Brezillon 2024-02-29 87 struct drm_gem_shmem_object *obj; 8a1cc07578bf42 Boris Brezillon 2024-02-29 88 struct panthor_kernel_bo *kbo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 89 struct panthor_gem_object *bo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 90 int ret; 8a1cc07578bf42 Boris Brezillon 2024-02-29 91 8a1cc07578bf42 Boris Brezillon 2024-02-29 92 if (drm_WARN_ON(&ptdev->base, !vm)) 8a1cc07578bf42 Boris Brezillon 2024-02-29 93 return ERR_PTR(-EINVAL); 8a1cc07578bf42 Boris Brezillon 2024-02-29 94 8a1cc07578bf42 Boris Brezillon 2024-02-29 95 kbo = kzalloc(sizeof(*kbo), GFP_KERNEL); 8a1cc07578bf42 Boris Brezillon 2024-02-29 96 if (!kbo) 8a1cc07578bf42 Boris Brezillon 2024-02-29 97 return ERR_PTR(-ENOMEM); 8a1cc07578bf42 Boris Brezillon 2024-02-29 98 8a1cc07578bf42 Boris Brezillon 2024-02-29 99 obj = drm_gem_shmem_create(&ptdev->base, size); 8a1cc07578bf42 Boris Brezillon 2024-02-29 100 if (IS_ERR(obj)) { 8a1cc07578bf42 Boris Brezillon 2024-02-29 101 ret = PTR_ERR(obj); 8a1cc07578bf42 Boris Brezillon 2024-02-29 102 goto err_free_bo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 103 } 8a1cc07578bf42 Boris Brezillon 2024-02-29 104 8a1cc07578bf42 Boris Brezillon 2024-02-29 105 bo = to_panthor_bo(&obj->base); 8a1cc07578bf42 Boris Brezillon 2024-02-29 106 kbo->obj = &obj->base; 8a1cc07578bf42 Boris Brezillon 2024-02-29 107 bo->flags = bo_flags; 8a1cc07578bf42 Boris Brezillon 2024-02-29 108 f48f05d54f7696 Adrián Larumbe 2025-04-11 109 panthor_gem_kernel_bo_set_label(kbo, name); f48f05d54f7696 Adrián Larumbe 2025-04-11 110 5d01b56f0518d8 Boris Brezillon 2024-10-30 111 /* The system and GPU MMU page size might differ, which becomes a 5d01b56f0518d8 Boris Brezillon 2024-10-30 112 * problem for FW sections that need to be mapped at explicit address 5d01b56f0518d8 Boris Brezillon 2024-10-30 113 * since our PAGE_SIZE alignment might cover a VA range that's 5d01b56f0518d8 Boris Brezillon 2024-10-30 114 * expected to be used for another section. 5d01b56f0518d8 Boris Brezillon 2024-10-30 115 * Make sure we never map more than we need. 5d01b56f0518d8 Boris Brezillon 2024-10-30 116 */ 5d01b56f0518d8 Boris Brezillon 2024-10-30 117 size = ALIGN(size, panthor_vm_page_size(vm)); 8a1cc07578bf42 Boris Brezillon 2024-02-29 118 ret = panthor_vm_alloc_va(vm, gpu_va, size, &kbo->va_node); 8a1cc07578bf42 Boris Brezillon 2024-02-29 119 if (ret) 8a1cc07578bf42 Boris Brezillon 2024-02-29 120 goto err_put_obj; 8a1cc07578bf42 Boris Brezillon 2024-02-29 121 8a1cc07578bf42 Boris Brezillon 2024-02-29 122 ret = panthor_vm_map_bo_range(vm, bo, 0, size, kbo->va_node.start, vm_map_flags); 8a1cc07578bf42 Boris Brezillon 2024-02-29 123 if (ret) 8a1cc07578bf42 Boris Brezillon 2024-02-29 124 goto err_free_va; 8a1cc07578bf42 Boris Brezillon 2024-02-29 125 ff60c8da0aaf7e Boris Brezillon 2024-05-02 126 kbo->vm = panthor_vm_get(vm); 8a1cc07578bf42 Boris Brezillon 2024-02-29 127 bo->exclusive_vm_root_gem = panthor_vm_root_gem(vm); 8a1cc07578bf42 Boris Brezillon 2024-02-29 128 drm_gem_object_get(bo->exclusive_vm_root_gem); 8a1cc07578bf42 Boris Brezillon 2024-02-29 129 bo->base.base.resv = bo->exclusive_vm_root_gem->resv; 8a1cc07578bf42 Boris Brezillon 2024-02-29 130 return kbo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 131 8a1cc07578bf42 Boris Brezillon 2024-02-29 132 err_free_va: 8a1cc07578bf42 Boris Brezillon 2024-02-29 133 panthor_vm_free_va(vm, &kbo->va_node); 8a1cc07578bf42 Boris Brezillon 2024-02-29 134 8a1cc07578bf42 Boris Brezillon 2024-02-29 135 err_put_obj: 8a1cc07578bf42 Boris Brezillon 2024-02-29 136 drm_gem_object_put(&obj->base); 8a1cc07578bf42 Boris Brezillon 2024-02-29 137 8a1cc07578bf42 Boris Brezillon 2024-02-29 138 err_free_bo: 8a1cc07578bf42 Boris Brezillon 2024-02-29 139 kfree(kbo); 8a1cc07578bf42 Boris Brezillon 2024-02-29 140 return ERR_PTR(ret); 8a1cc07578bf42 Boris Brezillon 2024-02-29 141 } 8a1cc07578bf42 Boris Brezillon 2024-02-29 142 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

8 months

1
0
0 0

[PATCH AUTOSEL 5.4 2/5] udmabuf: fix a buf size overflow issue during udmabuf creation

by Sasha Levin

From: Xiaogang Chen <xiaogang.chen(a)amd.com> [ Upstream commit 021ba7f1babd029e714d13a6bf2571b08af96d0f ] by casting size_limit_mb to u64 when calculate pglimit. Signed-off-by: Xiaogang Chen<Xiaogang.Chen(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250321164126.329638-1-xiaog… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/udmabuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index ae42e98cf8350..dfb572282097b 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -138,7 +138,7 @@ static long udmabuf_create(const struct udmabuf_create_list *head, if (!ubuf) return -ENOMEM; - pglimit = (size_limit_mb * 1024 * 1024) >> PAGE_SHIFT; + pglimit = ((u64)size_limit_mb * 1024 * 1024) >> PAGE_SHIFT; for (i = 0; i < head->count; i++) { if (!IS_ALIGNED(list[i].offset, PAGE_SIZE)) goto err; -- 2.39.5

8 months

1
0
0 0

[PATCH AUTOSEL 6.14 15/34] drm/amdgpu: allow pinning DMA-bufs into VRAM if all importers can do P2P

by Sasha Levin

From: Christian König <christian.koenig(a)amd.com> [ Upstream commit f5e7fabd1f5c65b2e077efcdb118cfa67eae7311 ] Try pinning into VRAM to allow P2P with RDMA NICs without ODP support if all attachments can do P2P. If any attachment can't do P2P just pin into GTT instead. Acked-by: Simona Vetter <simona.vetter(a)ffwll.ch> Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Felix Kuehling <felix.kuehling(a)amd.com> Reviewed-by: Felix Kuehling <felix.kuehling(a)amd.com> Tested-by: Pak Nin Lui <pak.lui(a)amd.com> Cc: Simona Vetter <simona.vetter(a)ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 25 +++++++++++++++------ 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index 9f627caedc3f6..ee47f239c8c12 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -75,11 +75,25 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf, */ static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach) { - struct drm_gem_object *obj = attach->dmabuf->priv; - struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj); + struct dma_buf *dmabuf = attach->dmabuf; + struct amdgpu_bo *bo = gem_to_amdgpu_bo(dmabuf->priv); + u32 domains = bo->preferred_domains; - /* pin buffer into GTT */ - return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT); + dma_resv_assert_held(dmabuf->resv); + + /* + * Try pinning into VRAM to allow P2P with RDMA NICs without ODP + * support if all attachments can do P2P. If any attachment can't do + * P2P just pin into GTT instead. + */ + list_for_each_entry(attach, &dmabuf->attachments, node) + if (!attach->peer2peer) + domains &= ~AMDGPU_GEM_DOMAIN_VRAM; + + if (domains & AMDGPU_GEM_DOMAIN_VRAM) + bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED; + + return amdgpu_bo_pin(bo, domains); } /** @@ -134,9 +148,6 @@ static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach, r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx); if (r) return ERR_PTR(r); - - } else if (bo->tbo.resource->mem_type != TTM_PL_TT) { - return ERR_PTR(-EBUSY); } switch (bo->tbo.resource->mem_type) { -- 2.39.5

8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig