Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 6/9] drm/{i915,xe}/fbdev: add intel_fbdev_fb_bo_destroy()
Date: Wed, 17 Sep 2025 15:33:31 +0300	[thread overview]
Message-ID: <4e4d1bc04de69092cdb3ecc16bda81764d2b9b16@intel.com> (raw)
In-Reply-To: <aLmkNu6AJ6LGVt6q@intel.com>

On Thu, 04 Sep 2025, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Sep 03, 2025 at 11:32:03PM +0300, Jani Nikula wrote:
>> xe does xe_bo_unpin_map_no_vm() on the failure path. Add a common helper
>> to enable further refactoring.
>> 
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> ---
>>  drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 5 +++++
>>  drivers/gpu/drm/i915/display/intel_fbdev_fb.h | 1 +
>>  drivers/gpu/drm/xe/display/intel_fbdev_fb.c   | 7 ++++++-
>>  3 files changed, 12 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
>> index 3837973b0d25..6b70823ce5ef 100644
>> --- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
>> +++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
>> @@ -51,6 +51,11 @@ struct drm_gem_object *intel_fbdev_fb_bo_create(struct drm_device *drm, int size
>>  	return &obj->base;
>>  }
>>  
>> +void intel_fbdev_fb_bo_destroy(struct drm_gem_object *obj)
>> +{
>> +	/* nop? */
>
> gem_object_put() is what destroys the bo on i915, so I think you're
> introducing a leak in the next patch with this nop implementation.
>
> xe seems to be riddled with footguns here since it conflates
> creation+pinning+whatever in the same thing (and I guess it
> doesn't know how to clean all that up when the last reference
> to the object disappears?) and you have to use that horribly
> misnamed function instead...

Hmm, can we just slap i915_gem_object_put(obj) in there?

The i915 variant of intel_fbdev_fb_alloc() ignores errors from
intel_framebuffer_create() and just unconditionally does
i915_gem_object_put() afterwards:

	fb = intel_framebuffer_create(intel_bo_to_drm_bo(obj),
				      drm_get_format_info(display->drm,
							  mode_cmd.pixel_format,
							  mode_cmd.modifier[0]),
				      &mode_cmd);
	i915_gem_object_put(obj);

	return to_intel_framebuffer(fb);

Presumably the refcounts are handled correctly either way.

It's just a bit fishy that the potential error pointer from
intel_framebuffer_create() goes through to_intel_framebuffer() to the
caller.

BR,
Jani.


>
>> +}
>> +
>>  struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_device *drm,
>>  					       struct drm_mode_fb_cmd2 *mode_cmd)
>>  {
>> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.h b/drivers/gpu/drm/i915/display/intel_fbdev_fb.h
>> index b10c4635bf46..6d6f316834df 100644
>> --- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.h
>> +++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.h
>> @@ -17,6 +17,7 @@ struct intel_display;
>>  
>>  u32 intel_fbdev_fb_pitch_align(u32 stride);
>>  struct drm_gem_object *intel_fbdev_fb_bo_create(struct drm_device *drm, int size);
>> +void intel_fbdev_fb_bo_destroy(struct drm_gem_object *obj);
>>  struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_device *drm,
>>  					       struct drm_mode_fb_cmd2 *mode_cmd);
>>  int intel_fbdev_fb_fill_info(struct intel_display *display, struct fb_info *info,
>> diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
>> index 9a5d14d5781a..9a5cf50ea7de 100644
>> --- a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
>> +++ b/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
>> @@ -54,6 +54,11 @@ struct drm_gem_object *intel_fbdev_fb_bo_create(struct drm_device *drm, int size
>>  	return &obj->ttm.base;
>>  }
>>  
>> +void intel_fbdev_fb_bo_destroy(struct drm_gem_object *obj)
>> +{
>> +	xe_bo_unpin_map_no_vm(gem_to_xe_bo(obj));
>> +}
>> +
>>  struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_device *drm,
>>  					       struct drm_mode_fb_cmd2 *mode_cmd)
>>  {
>> @@ -76,7 +81,7 @@ struct intel_framebuffer *intel_fbdev_fb_alloc(struct drm_device *drm,
>>  							  mode_cmd->modifier[0]),
>>  				      mode_cmd);
>>  	if (IS_ERR(fb)) {
>> -		xe_bo_unpin_map_no_vm(gem_to_xe_bo(obj));
>> +		intel_fbdev_fb_bo_destroy(obj);
>>  		goto err;
>>  	}
>>  
>> -- 
>> 2.47.2

-- 
Jani Nikula, Intel

  parent reply	other threads:[~2025-09-17 12:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 20:31 [PATCH 0/9] drm/{i915,xe}/fbdev: refactor Jani Nikula
2025-09-03 20:31 ` [PATCH 1/9] drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc() Jani Nikula
2025-09-03 20:31 ` [PATCH 2/9] drm/{i915,xe}/fbdev: add intel_fbdev_fb_pitch_align() Jani Nikula
2025-09-05  9:23   ` [PATCH 2/9] drm/{i915, xe}/fbdev: " Ville Syrjälä
2025-09-08 12:55     ` Jani Nikula
2025-09-08 14:19       ` Lucas De Marchi
2025-09-08 16:10         ` Maarten Lankhorst
2025-09-08 16:27           ` Ville Syrjälä
2025-09-16 11:44             ` Jani Nikula
2025-09-16 19:19               ` Ville Syrjälä
2025-09-18  8:43                 ` Jani Nikula
2025-10-13 13:52                   ` Jani Nikula
2025-10-13 17:19                     ` Ville Syrjälä
2025-10-14  4:48                       ` Hogander, Jouni
2025-09-03 20:32 ` [PATCH 3/9] drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init Jani Nikula
2025-09-03 20:32 ` [PATCH 4/9] drm/i915/fbdev: abstract bo creation Jani Nikula
2025-09-03 20:32 ` [PATCH 5/9] drm/xe/fbdev: " Jani Nikula
2025-09-03 20:32 ` [PATCH 6/9] drm/{i915,xe}/fbdev: add intel_fbdev_fb_bo_destroy() Jani Nikula
2025-09-04 14:37   ` Ville Syrjälä
2025-09-08 13:01     ` Jani Nikula
2025-09-17 12:33     ` Jani Nikula [this message]
2025-09-17 14:07       ` Ville Syrjälä
2025-09-18  8:46         ` Jani Nikula
2025-09-03 20:32 ` [PATCH 7/9] drm/{i915,xe}/fbdev: deduplicate fbdev creation Jani Nikula
2025-09-04 14:39   ` Ville Syrjälä
2025-09-08 12:57     ` Jani Nikula
2025-09-03 20:32 ` [PATCH 8/9] drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_fill_info() Jani Nikula
2025-09-03 20:32 ` [PATCH 9/9] drm/i915/fbdev: drop dependency on display in i915 specific code Jani Nikula
2025-09-03 21:15 ` ✓ i915.CI.BAT: success for drm/{i915,xe}/fbdev: refactor Patchwork
2025-09-05  1:09 ` ✗ i915.CI.Full: failure " Patchwork

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=4e4d1bc04de69092cdb3ecc16bda81764d2b9b16@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.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