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
next prev parent reply other threads:[~2025-09-17 12:33 UTC|newest]
Thread overview: 34+ 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 20:38 ` ✗ CI.checkpatch: warning for drm/{i915,xe}/fbdev: refactor Patchwork
2025-09-03 20:39 ` ✓ CI.KUnit: success " Patchwork
2025-09-03 21:11 ` ✓ Xe.CI.BAT: " Patchwork
2025-09-03 21:15 ` ✓ i915.CI.BAT: " Patchwork
2025-09-04 3:14 ` ✓ Xe.CI.Full: " 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 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.