dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Danilo Krummrich <dakr@redhat.com>
Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org,
	tzimmermann@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-misc-next 3/3] drm/vc4: crtc: protect device resources after removal
Date: Fri, 19 Aug 2022 09:29:30 +0200	[thread overview]
Message-ID: <20220819072930.fg56dkzbdu6f7s25@houat> (raw)
In-Reply-To: <20220819002905.82095-4-dakr@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3430 bytes --]

Hi,

On Fri, Aug 19, 2022 at 02:29:05AM +0200, Danilo Krummrich wrote:
> (Hardware) resources which are bound to the driver and device lifecycle
> must not be accessed after the device and driver are unbound.
> 
> However, the DRM device isn't freed as long as the last user closed it,
> hence userspace can still call into the driver.
> 
> Therefore protect the critical sections which are accessing those
> resources with drm_dev_enter() and drm_dev_exit().
> 
> Fixes: 7cc4214c27cf ("drm/vc4: crtc: Switch to drmm_kzalloc")
> Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 41 +++++++++++++++++++++++++++++++++-
>  1 file changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 2def6e2ad6f0..51daf190196e 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -39,6 +39,7 @@
>  #include <drm/drm_atomic_uapi.h>
>  #include <drm/drm_fb_dma_helper.h>
>  #include <drm/drm_framebuffer.h>
> +#include <drm/drm_drv.h>
>  #include <drm/drm_print.h>
>  #include <drm/drm_probe_helper.h>
>  #include <drm/drm_vblank.h>
> @@ -295,10 +296,17 @@ struct drm_encoder *vc4_get_crtc_encoder(struct drm_crtc *crtc,
>  static void vc4_crtc_pixelvalve_reset(struct drm_crtc *crtc)
>  {
>  	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> +	struct drm_device *dev = crtc->dev;
> +	int idx;
> +
> +	if (!drm_dev_enter(dev, &idx))
> +		return;
>  
>  	/* The PV needs to be disabled before it can be flushed */
>  	CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) & ~PV_CONTROL_EN);
>  	CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_FIFO_CLR);
> +
> +	drm_dev_exit(idx);
>  }
>  
>  static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct drm_encoder *encoder,
> @@ -321,6 +329,10 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct drm_encoder *encode
>  	u32 format = is_dsi1 ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
>  	u8 ppc = pv_data->pixels_per_clock;
>  	bool debug_dump_regs = false;
> +	int idx;
> +
> +	if (!drm_dev_enter(dev, &idx))
> +		return;
>  
>  	if (debug_dump_regs) {
>  		struct drm_printer p = drm_info_printer(&vc4_crtc->pdev->dev);
> @@ -410,6 +422,8 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct drm_encoder *encode
>  			 drm_crtc_index(crtc));
>  		drm_print_regset32(&p, &vc4_crtc->regset);
>  	}
> +
> +	drm_dev_exit(idx);
>  }
>  
>  static void require_hvs_enabled(struct drm_device *dev)
> @@ -430,13 +444,18 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
>  	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>  	struct drm_device *dev = crtc->dev;
>  	struct vc4_dev *vc4 = to_vc4_dev(dev);
> -	int ret;
> +	int idx, ret;
> +
> +	if (!drm_dev_enter(dev, &idx))
> +		return -ENODEV;
>  
>  	CRTC_WRITE(PV_V_CONTROL,
>  		   CRTC_READ(PV_V_CONTROL) & ~PV_VCONTROL_VIDEN);
>  	ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1);
>  	WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n");
>  
> +	drm_dev_exit(idx);
> +

I think this would be easier to follow if we were protecting the entire
function with our lock.

Having locks taken in the middle of the function is harder to identify
whether or not one particular function is safe or not.

The same applies to the plane patch

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2022-08-19  7:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  0:29 [PATCH drm-misc-next 0/3] Fixes for vc4 hotplug rework Danilo Krummrich
2022-08-19  0:29 ` [PATCH drm-misc-next 1/3] drm/vc4: hdmi: unlock mutex when device is unplugged Danilo Krummrich
2022-08-19  0:29 ` [PATCH drm-misc-next 2/3] drm/vc4: plane: protect device resources after removal Danilo Krummrich
2022-08-19  7:26   ` Maxime Ripard
2022-08-19 11:11     ` Danilo Krummrich
2022-08-19  0:29 ` [PATCH drm-misc-next 3/3] drm/vc4: crtc: " Danilo Krummrich
2022-08-19  7:29   ` Maxime Ripard [this message]

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=20220819072930.fg56dkzbdu6f7s25@houat \
    --to=maxime@cerno.tech \
    --cc=airlied@linux.ie \
    --cc=dakr@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tzimmermann@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).