| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 23 Feb 2022 13:00:12 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Rob Clark <robdclark@...il.com>, dri-devel@...ts.freedesktop.org
Cc: freedreno@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
Rob Clark <robdclark@...omium.org>,
Sean Paul <sean@...rly.run>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Kalyan Thota <quic_kalyant@...cinc.com>,
Stephen Boyd <swboyd@...omium.org>,
Krishna Manikandan <quic_mkrishn@...cinc.com>,
Mark Yacoub <markyacoub@...gle.com>,
Jessica Zhang <quic_jesszhan@...cinc.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Yangtao Li <tiny.windzz@...il.com>,
David Heidelberg <david@...t.cz>, Xu Wang <vulab@...as.ac.cn>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm: Avoid dirtyfb stalls on video mode displays
On 19/02/2022 22:39, Rob Clark wrote:
> From: Rob Clark <robdclark@...omium.org>
>
> Someone on IRC once asked an innocent enough sounding question: Why
> with xf86-video-modesetting is es2gears limited at 120fps.
>
> So I broke out the perfetto tracing mesa MR and took a look. It turns
> out the problem was drm_atomic_helper_dirtyfb(), which would end up
> waiting for vblank.. es2gears would rapidly push two frames to Xorg,
> which would blit them to screen and in idle hook (I assume) call the
> DIRTYFB ioctl. Which in turn would do an atomic update to flush the
> dirty rects, which would stall until the next vblank. And then the
> whole process would repeat.
>
> But this is a bit silly, we only need dirtyfb for command mode DSI
> panels. So lets just skip it otherwise.
>
> Signed-off-by: Rob Clark <robdclark@...omium.org>
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 13 +++++
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 9 ++++
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 9 ++++
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 1 +
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.h | 1 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 8 +++
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 1 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 1 +
> drivers/gpu/drm/msm/msm_fb.c | 64 ++++++++++++++++++++++-
> drivers/gpu/drm/msm/msm_kms.h | 2 +
> 11 files changed, 109 insertions(+), 1 deletion(-)
>
I have checked your previous dirtyfb patch (and corresponding discussion).
I'm not fond of the idea of acquiring locks, computing the value, then
releasing the locks and reacquiring the locks again. I understand the
original needs_dirtyfb approach was frowned upon. Do we have a chance of
introducing drm_atomic_helper_dirtyfb_unlocked()? Which would perform
all the steps of the orignal helper, but without locks acquirement (and
state allocation/freeing)?
[skipped]
> diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
> index 4d34df5354e0..1b0648baeae2 100644
> --- a/drivers/gpu/drm/msm/msm_fb.c
> +++ b/drivers/gpu/drm/msm/msm_fb.c
> @@ -24,10 +24,72 @@ struct msm_framebuffer {
> static struct drm_framebuffer *msm_framebuffer_init(struct drm_device *dev,
> const struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
>
> +static int msm_framebuffer_dirtyfb(struct drm_framebuffer *fb,
> + struct drm_file *file_priv, unsigned int flags,
> + unsigned int color, struct drm_clip_rect *clips,
> + unsigned int num_clips)
> +{
> + struct msm_drm_private *priv = fb->dev->dev_private;
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_plane *plane;
> + bool needs_flush = false;
> + int ret = 0;
> +
> + /*
> + * When called from ioctl, we are interruptible, but not when called
> + * internally (ie. defio worker)
> + */
> + drm_modeset_acquire_init(&ctx,
> + file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
> +
> +retry:
> + drm_for_each_plane(plane, fb->dev) {
> + struct drm_plane_state *plane_state;
> + struct drm_crtc *crtc;
> +
> + ret = drm_modeset_lock(&plane->mutex, &ctx);
> + if (ret)
> + goto out;
> +
> + if (plane->state->fb != fb) {
> + drm_modeset_unlock(&plane->mutex);
> + continue;
> + }
> +
> + crtc = plane->state->crtc;
> +
> + ret = drm_modeset_lock(&crtc->mutex, &ctx);
> + if (ret)
> + goto out;
> +
> + if (priv->kms->funcs->needs_dirtyfb(crtc)) {
> + needs_flush = true;
> + break;
> + }
> + }
> +
> +out:
> + if (ret == -EDEADLK) {
> + ret = drm_modeset_backoff(&ctx);
> + if (!ret)
> + goto retry;
> + }
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> + if (needs_flush) {
This bit triggers my paranoia. The driver computes the value with the
locks being held and then performs some action depending on the computed
value after releasing the locks.
I'd prefer to acquire modesetting locks for all the planes (and allocate
atomic state), check if the dirtyfb processing is needed, then call
drm_atomic_helper_dirtyfb_unlocked() withith the same locks section.
> + ret = drm_atomic_helper_dirtyfb(fb, file_priv, flags,
> + color, clips, num_clips);
> + }
> +
> + return ret;
> +}
> +
> static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
> .create_handle = drm_gem_fb_create_handle,
> .destroy = drm_gem_fb_destroy,
> - .dirty = drm_atomic_helper_dirtyfb,
> + .dirty = msm_framebuffer_dirtyfb,
> };
>
> #ifdef CONFIG_DEBUG_FS
> diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
> index 2a4f0526cb98..eb870d499d1e 100644
> --- a/drivers/gpu/drm/msm/msm_kms.h
> +++ b/drivers/gpu/drm/msm/msm_kms.h
> @@ -117,6 +117,8 @@ struct msm_kms_funcs {
> struct drm_encoder *encoder,
> struct drm_encoder *slave_encoder,
> bool is_cmd_mode);
> + bool (*needs_dirtyfb)(struct drm_crtc *crtc);
> +
> /* cleanup: */
> void (*destroy)(struct msm_kms *kms);
>
--
With best wishes
Dmitry
Powered by blists - more mailing lists