From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5132F13B293 for ; Mon, 24 Aug 2026 08:14:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787559269; cv=none; b=RseUpiwtt31a2g5gi1HTnATIOxAx4ed9bdSFtB9CCfJsMTeI/QQqC9jqOc3PESiQ+WVHvUUiusgOl8kHZMw5duvRoMzllM2+YclTfZRXSxPfJcHML1Ez6Hxp/H5Q7h8Et+O261XPq7+67hNI8OJ4WHS0ABddAx9jOf0fzkcg6vs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787559269; c=relaxed/simple; bh=dNn7+3rsBa8HQJx84xgDlGmD5XExMp7xGbx5W66x/R4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Aqr23irAHWZDEvLyK8u7xZOQLrCjrIBWOTRAQwjbRb990NOM4npWjlUlJrVLFde+32SEqh+MN3BwgWKodBmeA55RR55kgCr3ZabUhDg7HTWVjWroJXnt6YL7gyDgBEApp8w9Fav9OIOErW3UG2EGrQyhahRjAl48VXs/URCf0LM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=HFD4utzX; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="HFD4utzX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1787559266; bh=dNn7+3rsBa8HQJx84xgDlGmD5XExMp7xGbx5W66x/R4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HFD4utzXAJbPoPxOd8Wm9m6XnLD1TQ5PaGe3ddKFJflpwkMIwzKSTNyMVN1ccMRrn xhSsh19ZYmZxMtkZTpEQhi6SHXzz403WWFWkjIJWWOXREphpn+Y5jgHoiHYNnMjbVE BVIh0y4CpJGLer3A5Pb5Saf3zhVk8292lzhGeAImMKIpD2FwggaHSc3tmC2URerUr6 Iq9Po45xXk7GMvMlzZfAwjlO4QXrJpztQbQgfq3XOpr2rWcS43cyDyqMtgXAppMNrh UMJHWUYrR2av9h1TOVkhTlTrFqPXWCc0QqvtPEXoQ7yDzeJSoaypXx+YAtLQoH+QY0 +LCA19VAT8O3Q== Received: from fedora-21.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id E2B7617E084E; Mon, 24 Aug 2026 10:14:25 +0200 (CEST) Date: Mon, 24 Aug 2026 10:14:20 +0200 From: Boris Brezillon To: Nicolas Frattaroli Cc: Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , kernel@collabora.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/panthor: Display priorities of panthor groups over debugfs Message-ID: <20260824101420.36380185@fedora-21.home> In-Reply-To: <20260818-panthor-sched-group-prio-v1-1-1836857c53e9@collabora.com> References: <20260818-panthor-sched-group-prio-v1-1-1836857c53e9@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello Nicolas, On Tue, 18 Aug 2026 21:35:24 +0200 Nicolas Frattaroli wrote: > Analogous to what was added in Commit d41c79838c47 ("drm/panfrost: > Display list of device JM contexts over debugfs") for panfrost, add > similar debugfs information for panthor. > > The group priority does not change over the lifetime of the group, so no > effort to synchronise with the scheduler lock is being made. > > Signed-off-by: Nicolas Frattaroli > --- > Some additional notes: I noticed panthor apparently uses > xa_for_each{_marked} by guarding it with xa_lock/xa_unlock. That appears > to be unnecessary, judging by the documentation of it and that nobody > else does this. > --- > drivers/gpu/drm/panthor/panthor_drv.c | 1 + > drivers/gpu/drm/panthor/panthor_sched.c | 89 +++++++++++++++++++++++++++++++++ > drivers/gpu/drm/panthor/panthor_sched.h | 5 ++ > 3 files changed, 95 insertions(+) > > diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c > index 46a3080b0b20..8cdba0c1a14b 100644 > --- a/drivers/gpu/drm/panthor/panthor_drv.c > +++ b/drivers/gpu/drm/panthor/panthor_drv.c > @@ -1769,6 +1769,7 @@ static void panthor_debugfs_init(struct drm_minor *minor) > { > panthor_mmu_debugfs_init(minor); > panthor_gem_debugfs_init(minor); > + panthor_sched_debugfs_init(minor); > } > #endif > > diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c > index 5832dccfc093..44b61e946e2d 100644 > --- a/drivers/gpu/drm/panthor/panthor_sched.c > +++ b/drivers/gpu/drm/panthor/panthor_sched.c > @@ -1,6 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0 or MIT > /* Copyright 2023 Collabora ltd. */ > > +#include > #include > #include > #include > @@ -4198,3 +4199,91 @@ int panthor_sched_init(struct panthor_device *ptdev) > ptdev->scheduler = sched; > return 0; > } > + > +#ifdef CONFIG_DEBUG_FS > + > +static const char * > +panthor_sched_prio_str(enum panthor_csg_priority prio) > +{ > + switch (prio) { > + case PANTHOR_CSG_PRIORITY_LOW: > + return "LOW"; > + case PANTHOR_CSG_PRIORITY_MEDIUM: > + return "MEDIUM"; > + case PANTHOR_CSG_PRIORITY_HIGH: > + return "HIGH"; > + case PANTHOR_CSG_PRIORITY_RT: > + return "REAL-TIME"; > + default: > + return "UNKNOWN"; > + } > +} > + > +static int show_file_groups(struct panthor_file *pfile, struct seq_file *m) > +{ > + struct panthor_group *group; > + unsigned long i; > + > + if (IS_ERR_OR_NULL(pfile->groups)) > + return -ENOENT; > + > + xa_for_each_marked(&pfile->groups->xa, i, group, GROUP_REGISTERED) { > + seq_printf(m, " Group %lu: priority %s\n", i, > + panthor_sched_prio_str(group->priority)); > + } Could this race with the GROUP_DESTROY ioctl and open the door for potential UAFs on the group object? Seems panthor_fdinfo_gather_group_samples() has this xa_for_each_marked() inside an xa_lock()-ed section to cover for this. > + > + return 0; > +} > + > +static int show_each_file(struct seq_file *m, void *arg) > +{ > + struct drm_info_node *node = (struct drm_info_node *)m->private; > + struct drm_device *ddev = node->minor->dev; > + int (*show)(struct panthor_file *, struct seq_file *) = > + node->info_ent->data; > + struct drm_file *file; > + int ret = 0; > + > + scoped_cond_guard(mutex_intr, return -EINTR, &ddev->filelist_mutex) { > + list_for_each_entry(file, &ddev->filelist, lhead) { > + struct task_struct *task; > + struct panthor_file *pfile = file->driver_priv; > + struct pid *pid; > + > + /* > + * Although we have a valid reference on file->pid, that does > + * not guarantee that the task_struct who called get_pid() is > + * still alive (e.g. get_pid(current) => fork() => exit()). > + * Therefore, we need to protect this ->comm access using RCU. > + */ > + rcu_read_lock(); > + pid = rcu_dereference(file->pid); > + task = pid_task(pid, PIDTYPE_TGID); > + seq_printf(m, "client_id %8llu pid %8d command %s:\n", > + file->client_id, pid_nr(pid), > + task ? task->comm : ""); > + rcu_read_unlock(); Don't we have this piece of information stored in panthor_group::task_info already? Unless you really want to reflect clients that have no groups, or have groups from a given client clearly outlined in the debugfs output, I'd flatten things out and have these client-related info printed along the group info in show_file_groups() (pass a drm_file instead of a panthor_file, so you can get the client_id from there). Regards, Boris > + > + ret = show(pfile, m); > + if (ret < 0) > + break; > + > + seq_puts(m, "\n"); > + } > + } > + > + return ret;