All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: "Steven Price" <steven.price@arm.com>,
	"Liviu Dudau" <liviu.dudau@arm.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	kernel@collabora.com, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH v4 4/4] drm/panthor: show device-wide list of DRM GEM objects over DebugFS
Date: Tue, 8 Apr 2025 16:46:52 +0200	[thread overview]
Message-ID: <20250408164652.2cc26723@collabora.com> (raw)
In-Reply-To: <k5pf4wkpaeuahdg5vasxo226jppjxtndkswoi2g72eezecttic@vrdnyjxbqont>

On Tue, 8 Apr 2025 15:38:18 +0100
Adrián Larumbe <adrian.larumbe@collabora.com> wrote:

> On 08.04.2025 15:47, Boris Brezillon wrote:
> On Tue, 8 Apr 2025 14:38:44 +0100
> Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
> 
> > > > > diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
> > > > > index 44d027e6d664..2fc87be9b700 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@kernel.org> */
> > > > >  /* Copyright 2023 Collabora ltd. */
> > > > >
> > > > > +#include <linux/cleanup.h>
> > > > >  #include <linux/dma-buf.h>
> > > > >  #include <linux/dma-mapping.h>
> > > > >  #include <linux/err.h>
> > > > > @@ -10,14 +11,65 @@
> > > > >  #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_init(struct panthor_gem_object *bo, u32 type_mask)
> > > > > +{
> > > > > +	INIT_LIST_HEAD(&bo->debugfs.node);  
> > > >
> > > > This should be called when the GEM object is created, otherwise the
> > > > list_empty() test done in panthor_gem_debugfs_bo_rm() will only work if
> > > > panthor_gem_debugfs_bo_add() is called, and depending on when this
> > > > happens, or whether it happens at all, the error path will do a NULL
> > > > deref.  
> > >
> > > I'll be moving panthor_gem_debugfs_bo_add() back into panthor_gem_create_object() and
> > > inline panthor_gem_debugfs_bo_init() into it.  
> >
> > You mean moving the panthor_gem_debugfs_bo_add() call to
> > panthor_gem_create_object(), not inlining its content, right?  
> 
> Yes, inlining panthor_gem_debugfs_bo_init() into panthor_gem_debugfs_bo_add() and moving
> panthor_gem_debugfs_bo_add() into panthor_gem_create_object().
> 
> > > > > +	} else {
> > > > > +		bo->debugfs.creator.tgid = 0;
> > > > > +		snprintf(bo->debugfs.creator.process_name,
> > > > > +			 sizeof(bo->debugfs.creator.process_name),
> > > > > +			 "kernel");
> > > > > +	}
> > > > > +
> > > > > +	bo->debugfs.bo_mask = type_mask;  
> > > >
> > > > Why not do that directly in panthor_gem_debugfs_bo_add()? The only bits
> > > > that might be useful to do early is the INIT_LIST_HEAD(), and I think
> > > > it can be inlined in panthor_gem_create_object().  
> > >
> > > I'll be doing in this in the next revision, but because I've no access to the BO
> > > type mask from inside Panthor's drm_driver::gem_create_object() binding, then
> > > I'll have to assign the mask right after the object has been created.
> > >
> > > I think this means there might be a short window after the object's been added to
> > > the DebugFS GEMs list in which it could be shown with the kernel mask field still
> > > set to 0, but I guess that's not too important either.  
> >
> > I think it's okay, as long as you don't crash when printing partially
> > initialized objects. Another solution would be to have a flag encoding
> > when the obj is initialized, so you can skip objects that don't have
> > this flag set yet.  
> 
> I think what I'll do is set the mask to a poison value, maybe 0xFF, and only when
> it's overwritten with a legitimate value, display the object in the DebugFS GEMS file.

Well, it's just as simple to leave it to zero at bo_add() time, and
have an INITIALIZED flag that you set along the other flags in the
caller of gem_shmem_create(). If you make it a poison value, you'll
need to make sure it never conflicts with a valid flag combination,
which might be annoying.

  reply	other threads:[~2025-04-08 14:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 11:54 [PATCH v4 0/4] Panthor BO tagging and GEMS debug display Adrián Larumbe
2025-04-02 11:54 ` [PATCH v4 1/4] drm/panthor: Introduce BO labeling Adrián Larumbe
2025-04-02 11:54 ` [PATCH v4 2/4] drm/panthor: Add driver IOCTL for setting BO labels Adrián Larumbe
2025-04-07 13:36   ` Liviu Dudau
2025-04-02 11:54 ` [PATCH v4 3/4] drm/panthor: Label all kernel BO's Adrián Larumbe
2025-04-02 13:08   ` Boris Brezillon
2025-04-02 11:54 ` [PATCH v4 4/4] drm/panthor: show device-wide list of DRM GEM objects over DebugFS Adrián Larumbe
2025-04-02 12:58   ` Boris Brezillon
2025-04-08 13:38     ` Adrián Larumbe
2025-04-08 13:47       ` Boris Brezillon
2025-04-08 14:38         ` Adrián Larumbe
2025-04-08 14:46           ` Boris Brezillon [this message]
2025-04-08 15:26   ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250408164652.2cc26723@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=adrian.larumbe@collabora.com \
    --cc=airlied@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.