Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	"Jouni Högander" <jouni.hogander@intel.com>
Subject: Re: [PATCH 1/4] drm/i915/fb: Fix the set_tiling vs. addfb race, again
Date: Thu, 2 Oct 2025 19:41:32 +0300	[thread overview]
Message-ID: <aN6rPMvuI0NkXYwG@intel.com> (raw)
In-Reply-To: <053828a8f31f70e964d3f620a56e75d395f98172@intel.com>

On Thu, Oct 02, 2025 at 04:59:51PM +0300, Jani Nikula wrote:
> On Thu, 02 Oct 2025, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > intel_frontbuffer_get() is what locks out subsequent set_tiling
> > changes to the bo. Thus the fence vs. modifier check must be done
> > after intel_frontbuffer_get(), or else a concurrent set_tiling ioctl
> > might sneak in and change the fence after the check has been done.
> >
> > Close the race again. See commit dd689287b977 ("drm/i915: Prevent
> > concurrent tiling/framebuffer modifications") for the previous
> > instance.
> >
> > Cc: Jouni Högander <jouni.hogander@intel.com>
> > Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini")
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_fb.c | 38 +++++++++++++------------
> >  1 file changed, 20 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c
> > index 69237dabdae8..c5bbca7f2e8b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -2218,15 +2218,17 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  	int ret = -EINVAL;
> >  	int i;
> >  
> > -	ret = intel_fb_bo_framebuffer_init(fb, obj, mode_cmd);
> > -	if (ret)
> > -		return ret;
> > -
> > +	/*
> > +	 * intel_frontbuffer_get() must be done before
> > +	 * intel_fb_bo_framebuffer_init() to avoid set_tiling vs. addfb race.
> > +	 */
> >  	intel_fb->frontbuffer = intel_frontbuffer_get(obj);
> > -	if (!intel_fb->frontbuffer) {
> > -		ret = -ENOMEM;
> > -		goto err;
> > -	}
> > +	if (!intel_fb->frontbuffer)
> > +		return -ENOMEM;
> > +
> > +	ret = intel_fb_bo_framebuffer_init(fb, obj, mode_cmd);
> > +	if (ret)
> > +		goto err_frontbuffer_put;
> 
> Do you think we should modify intel_user_framebuffer_destroy() to also
> have the same put & fini order here, just for consistency?

Sounds reasonable. I'll send a v2.

> 
> I think this should be merged before my leak fix, and that should be
> rebased [1], to make the backports easier.
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> 
> 
> [1] https://lore.kernel.org/r/20251002101756.2700320-1-jani.nikula@intel.com
> 
> >  
> >  	ret = -EINVAL;
> >  	if (!drm_any_plane_has_format(display->drm,
> > @@ -2235,7 +2237,7 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  		drm_dbg_kms(display->drm,
> >  			    "unsupported pixel format %p4cc / modifier 0x%llx\n",
> >  			    &mode_cmd->pixel_format, mode_cmd->modifier[0]);
> > -		goto err_frontbuffer_put;
> > +		goto err_bo_framebuffer_fini;
> >  	}
> >  
> >  	max_stride = intel_fb_max_stride(display, mode_cmd->pixel_format,
> > @@ -2246,7 +2248,7 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  			    mode_cmd->modifier[0] != DRM_FORMAT_MOD_LINEAR ?
> >  			    "tiled" : "linear",
> >  			    mode_cmd->pitches[0], max_stride);
> > -		goto err_frontbuffer_put;
> > +		goto err_bo_framebuffer_fini;
> >  	}
> >  
> >  	/* FIXME need to adjust LINOFF/TILEOFF accordingly. */
> > @@ -2254,7 +2256,7 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  		drm_dbg_kms(display->drm,
> >  			    "plane 0 offset (0x%08x) must be 0\n",
> >  			    mode_cmd->offsets[0]);
> > -		goto err_frontbuffer_put;
> > +		goto err_bo_framebuffer_fini;
> >  	}
> >  
> >  	drm_helper_mode_fill_fb_struct(display->drm, fb, info, mode_cmd);
> > @@ -2264,7 +2266,7 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  
> >  		if (mode_cmd->handles[i] != mode_cmd->handles[0]) {
> >  			drm_dbg_kms(display->drm, "bad plane %d handle\n", i);
> > -			goto err_frontbuffer_put;
> > +			goto err_bo_framebuffer_fini;
> >  		}
> >  
> >  		stride_alignment = intel_fb_stride_alignment(fb, i);
> > @@ -2272,7 +2274,7 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  			drm_dbg_kms(display->drm,
> >  				    "plane %d pitch (%d) must be at least %u byte aligned\n",
> >  				    i, fb->pitches[i], stride_alignment);
> > -			goto err_frontbuffer_put;
> > +			goto err_bo_framebuffer_fini;
> >  		}
> >  
> >  		if (intel_fb_is_gen12_ccs_aux_plane(fb, i)) {
> > @@ -2282,7 +2284,7 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  				drm_dbg_kms(display->drm,
> >  					    "ccs aux plane %d pitch (%d) must be %d\n",
> >  					    i, fb->pitches[i], ccs_aux_stride);
> > -				goto err_frontbuffer_put;
> > +				goto err_bo_framebuffer_fini;
> >  			}
> >  		}
> >  
> > @@ -2291,7 +2293,7 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  
> >  	ret = intel_fill_fb_info(display, intel_fb);
> >  	if (ret)
> > -		goto err_frontbuffer_put;
> > +		goto err_bo_framebuffer_fini;
> >  
> >  	if (intel_fb_uses_dpt(fb)) {
> >  		struct i915_address_space *vm;
> > @@ -2317,10 +2319,10 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >  err_free_dpt:
> >  	if (intel_fb_uses_dpt(fb))
> >  		intel_dpt_destroy(intel_fb->dpt_vm);
> > -err_frontbuffer_put:
> > -	intel_frontbuffer_put(intel_fb->frontbuffer);
> > -err:
> > +err_bo_framebuffer_fini:
> >  	intel_fb_bo_framebuffer_fini(obj);
> > +err_frontbuffer_put:
> > +	intel_frontbuffer_put(intel_fb->frontbuffer);
> >  	return ret;
> >  }
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-10-02 16:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-02 11:54 [PATCH 0/4] drm/i915: fb fixes and claenups Ville Syrjala
2025-10-02 11:54 ` [PATCH 1/4] drm/i915/fb: Fix the set_tiling vs. addfb race, again Ville Syrjala
2025-10-02 13:59   ` Jani Nikula
2025-10-02 16:41     ` Ville Syrjälä [this message]
2025-10-02 16:44   ` [PATCH v2 " Ville Syrjala
2025-10-02 11:54 ` [PATCH 2/4] drm/i915/fbdev: Select linear modifier explicitly Ville Syrjala
2025-10-02 14:25   ` Jani Nikula
2025-10-02 11:54 ` [PATCH 3/4] drm/i915/fb: Drop the 'fb' argument from intel_fb_bo_framebuffer_init() Ville Syrjala
2025-10-02 14:27   ` Jani Nikula
2025-10-02 11:54 ` [PATCH 4/4] drm/i915/wm: Use fb->modfier to check for tiled vs. untiled Ville Syrjala
2025-10-02 15:05   ` Jani Nikula
2025-10-02 15:41 ` ✓ i915.CI.BAT: success for drm/i915: fb fixes and claenups Patchwork
2025-10-02 18:53 ` ✓ i915.CI.BAT: success for drm/i915: fb fixes and claenups (rev2) Patchwork
2025-10-03 10:49 ` ✓ i915.CI.Full: " 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=aN6rPMvuI0NkXYwG@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jouni.hogander@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