Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	Jocelyn Falempe <jfalempe@redhat.com>,
	Maarten Lankhorst <dev@lankhorst.se>
Subject: Re: [PATCH 6/8] drm/{i915,xe}/panic: move framebuffer allocation where it belongs
Date: Wed, 1 Oct 2025 20:43:51 +0300	[thread overview]
Message-ID: <aN1oV1c2au8kdoBe@intel.com> (raw)
In-Reply-To: <413d3e0fc6e6bc10ed22b7d7fa9771ab8fbaf414@intel.com>

On Wed, Oct 01, 2025 at 08:28:53PM +0300, Jani Nikula wrote:
> On Wed, 01 Oct 2025, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Wed, Oct 01, 2025 at 06:04:58PM +0300, Jani Nikula wrote:
> >> On Tue, 02 Sep 2025, Jani Nikula <jani.nikula@intel.com> wrote:
> >> > The struct intel_framebuffer allocation naturally belongs in intel_fb.c,
> >> > not hidden inside panic implementation. Separate the panic
> >> > allocation. Drop the unnecessary struct i915_framebuffer and struct
> >> > xe_framebuffer types.
> >> >
> >> > Cc: Jocelyn Falempe <jfalempe@redhat.com>
> >> > Cc: Maarten Lankhorst <dev@lankhorst.se>
> >> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_fb.c    | 17 ++++++++++++++++-
> >> >  drivers/gpu/drm/i915/display/intel_panic.c |  4 ++--
> >> >  drivers/gpu/drm/i915/display/intel_panic.h |  3 ++-
> >> >  drivers/gpu/drm/i915/gem/i915_gem_object.h |  5 +++--
> >> >  drivers/gpu/drm/i915/gem/i915_gem_pages.c  | 17 ++++-------------
> >> >  drivers/gpu/drm/xe/display/xe_panic.c      | 17 ++++-------------
> >> >  6 files changed, 31 insertions(+), 32 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c
> >> > index 2a2ed0f0461f..22a4a1575d22 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> >> > @@ -2346,7 +2346,22 @@ intel_user_framebuffer_create(struct drm_device *dev,
> >> >  
> >> >  struct intel_framebuffer *intel_framebuffer_alloc(void)
> >> >  {
> >> > -	return intel_bo_alloc_framebuffer();
> >> > +	struct intel_framebuffer *intel_fb;
> >> > +	struct intel_panic *panic;
> >> > +
> >> > +	intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
> >> > +	if (!intel_fb)
> >> > +		return NULL;
> >> > +
> >> > +	panic = intel_panic_alloc();
> >> > +	if (!panic) {
> >> > +		kfree(intel_fb);
> >> > +		return NULL;
> >> > +	}
> >> > +
> >> > +	intel_fb->panic = panic;
> >> 
> >> So I screwed up here. There's no deallocation of fb->panic, and this
> >> leaks. I don't know what I was thinking.
> >> 
> >> To make matters worse, struct intel_framebuffer is deallocated via
> >> drm_framebuffer_put() i.e. there's no obvious place to plug the free in.
> >
> > intel_user_framebuffer_destroy()
> 
> D'oh! I still wasn't thinking it appears. Thanks.
> 
> Still not straightforward with the alloc and init split in
> i9xx_get_initial_plane_config()/skl_get_initial_plane_config() and the
> intel_alloc_initial_plane_obj() implementations.
> 
> I think the framebuffer leaked on the error paths already before my
> change, so I guess I could just plug what I caused.

Maybe just move the panic alloc into intel_framebuffer_init()?

Hmm, looks like someone opened the small race there again with the
intel_frontbuffer_get() vs. intel_fb_bo_framebuffer_init() reodering.
I'll need to fix that again...

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-10-01 17:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 17:51 [PATCH 0/8] drm/{i915, xe}/panic: refactor framebuffer allocation etc Jani Nikula
2025-09-02 17:51 ` [PATCH 1/8] drm/i915/fb: add intel_framebuffer_alloc() Jani Nikula
2025-09-02 17:51 ` [PATCH 2/8] drm/{i915,xe}/panic: split out intel_panic.[ch] Jani Nikula
2025-09-02 17:51 ` [PATCH 3/8] drm/{i915, xe}/panic: rename intel_bo_panic_*() to intel_panic_*() Jani Nikula
2025-09-02 17:51 ` [PATCH 4/8] drm/{i915, xe}/fb: add panic pointer member to struct intel_framebuffer Jani Nikula
2025-09-02 17:51 ` [PATCH 5/8] drm/{i915, xe}/panic: rename struct {i915, xe}_panic_data to struct intel_panic Jani Nikula
2025-09-02 17:51 ` [PATCH 6/8] drm/{i915, xe}/panic: move framebuffer allocation where it belongs Jani Nikula
2025-10-01 15:04   ` [PATCH 6/8] drm/{i915,xe}/panic: " Jani Nikula
2025-10-01 16:37     ` Ville Syrjälä
2025-10-01 17:28       ` Jani Nikula
2025-10-01 17:43         ` Ville Syrjälä [this message]
2025-09-02 17:51 ` [PATCH 7/8] drm/{i915, xe}/panic: convert intel_panic_finish() to struct intel_panic Jani Nikula
2025-09-02 17:51 ` [PATCH 8/8] drm/{i915, xe}/panic: pass struct intel_panic to intel_panic_setup() Jani Nikula
2025-09-02 18:48 ` ✗ CI.checkpatch: warning for drm/{i915, xe}/panic: refactor framebuffer allocation etc Patchwork
2025-09-02 18:50 ` ✓ CI.KUnit: success " Patchwork
2025-09-02 19:05 ` ✗ CI.checksparse: warning " Patchwork
2025-09-02 19:25 ` ✓ Xe.CI.BAT: success " Patchwork
2025-09-03  2:28 ` ✗ Xe.CI.Full: failure " Patchwork
2025-09-04 11:46 ` [PATCH 0/8] " Jocelyn Falempe
2025-09-08 11:29   ` [PATCH 0/8] drm/{i915,xe}/panic: " Jani Nikula

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=aN1oV1c2au8kdoBe@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dev@lankhorst.se \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=jfalempe@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox