All of 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: 22+ 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-02 20:51 ` ✓ i915.CI.BAT: " Patchwork
2025-09-03  2:28 ` ✗ Xe.CI.Full: failure " Patchwork
2025-09-03  7:05 ` ✗ i915.CI.Full: " 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 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.