All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: imre.deak@intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Fix a use-after-free when intel_edp_init_connector fails
Date: Thu, 11 May 2023 11:39:18 +0300	[thread overview]
Message-ID: <877ctfmfd5.fsf@intel.com> (raw)
In-Reply-To: <Y6II2T9SCtc1uZC6@ideak-desk.fi.intel.com>

On Tue, 20 Dec 2022, Imre Deak <imre.deak@intel.com> wrote:
> On Tue, Dec 20, 2022 at 02:40:47PM +0200, Jani Nikula wrote:
>> On Tue, 20 Dec 2022, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
>> > We enable the DP aux channel during probe, but may free the connector
>> > soon afterwards. Ensure the DP aux display power put is completed before
>> > everything is freed, to prevent a use-after-free in icl_aux_pw_to_phy(),
>> > called from icl_combo_phy_aux_power_well_disable.
>> 
>> Feels like the placement of the intel_display_power_flush_work_sync()
>> call in intel_dp_aux_fini() is a bit arbitrary.
>> 
>> If we add it in intel_dp_aux_fini(), the async and sync waits will both
>> be called on the regular encoder destroy path.
>
> Yes, calling intel_display_power_flush_work() from the error handler at
> the end of intel_dp_init_connector() would be better.
>
>> Maybe both intel_ddi_encoder_destroy() and intel_dp_encoder_destroy()
>> should call intel_display_power_flush_work_sync(), instead of async,
>
> intel_display_power_flush_work() ensures that power wells without a
> reference held are disabled when it returns, so no need to call the
> _sync() version for encoders (the _sync() version ensures in addition
> during driver unloading that the work function is not running).
>
>> and maybe the error paths should call those functions instead of just
>> drm_encoder_cleanup()?
>
> Yes, the cleanup in those functions could be shared with the error
> handling in g4x_dp_init() and intel_ddi_init(), except kfree(dig_port)
> which also happens if drm_encoder_init() fails. 
>
> For this intel_pps_vdd_off_sync() / intel_dp_aux_fini() would also
> happen later at the end of g4x_dp_init()/intel_ddi_init(), I guess
> that's ok.
>
> I wonder if not handling drm_encoder_init() error in intel_ddi_init()
> was on purpose, can't see a reason for it.

This patch has been forgotten...

Maarten, can you follow up on it please?

BR,
Jani.


>
>> Imre?
>> 
>> 
>> BR,
>> Jani.
>> 
>> 
>> >
>> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
>> >  drivers/gpu/drm/i915/display/intel_display_power.h | 1 +
>> >  drivers/gpu/drm/i915/display/intel_dp_aux.c        | 2 ++
>> >  3 files changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c
>> > index 04915f85a0df..0edb5532461f 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>> > @@ -776,7 +776,7 @@ void intel_display_power_flush_work(struct drm_i915_private *i915)
>> >   * Like intel_display_power_flush_work(), but also ensure that the work
>> >   * handler function is not running any more when this function returns.
>> >   */
>> > -static void
>> > +void
>> >  intel_display_power_flush_work_sync(struct drm_i915_private *i915)
>> >  {
>> >  	struct i915_power_domains *power_domains = &i915->display.power.domains;
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h b/drivers/gpu/drm/i915/display/intel_display_power.h
>> > index 7136ea3f233e..dc10ee0519e6 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
>> > @@ -188,6 +188,7 @@ void __intel_display_power_put_async(struct drm_i915_private *i915,
>> >  				     enum intel_display_power_domain domain,
>> >  				     intel_wakeref_t wakeref);
>> >  void intel_display_power_flush_work(struct drm_i915_private *i915);
>> > +void intel_display_power_flush_work_sync(struct drm_i915_private *i915);
>> >  #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
>> >  void intel_display_power_put(struct drm_i915_private *dev_priv,
>> >  			     enum intel_display_power_domain domain,
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c
>> > index f1835c74bff0..1006dddad2d5 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
>> > @@ -680,6 +680,8 @@ void intel_dp_aux_fini(struct intel_dp *intel_dp)
>> >  	if (cpu_latency_qos_request_active(&intel_dp->pm_qos))
>> >  		cpu_latency_qos_remove_request(&intel_dp->pm_qos);
>> >  
>> > +	/* Ensure async work from intel_dp_aux_xfer() is flushed before we clean up */
>> > +	intel_display_power_flush_work_sync(dp_to_i915(intel_dp));
>> >  	kfree(intel_dp->aux.name);
>> >  }
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-05-11  8:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20  9:46 [Intel-gfx] [PATCH] drm/i915/display: Fix a use-after-free when intel_edp_init_connector fails Maarten Lankhorst
2022-12-20 12:40 ` Jani Nikula
2022-12-20 19:11   ` Imre Deak
2023-05-11  8:39     ` Jani Nikula [this message]
2022-12-21 23:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-12-22  1:58 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=877ctfmfd5.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.