linux-kernel - [PATCH] drm/vkms: Avoid extra discount in the timestamp value

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20190520001208.yh4jivl5lcc7iarh@smtp.gmail.com>
Date:   Sun, 19 May 2019 21:12:08 -0300
From:   Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>
To:     Ville Syrjala <ville.syrjala@...ux.intel.com>,
        Shayenne Moura <shayenneluzmoura@...il.com>,
        Haneen Mohammed <hamohammed.sa@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>
Cc:     dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: [PATCH] drm/vkms: Avoid extra discount in the timestamp value

After the commit def35e7c5926 ("drm/vkms: Bugfix extra vblank frame")
some of the crc tests (IGT) start to fail in the vkms with the following
error:

 [drm:drm_crtc_add_crc_entry [drm]] *ERROR* Overflow of CRC buffer,
    userspace reads too slow.
 [drm] failed to queue vkms_crc_work_handle
 ...

The commit def35e7c5926 ("drm/vkms: Bugfix extra vblank frame") added an
operation for decrement the timestamp value returned by
`get_vblank_timestamp()` which solved the problems related to kms_flip
tests. However, each call to `get_vblank_timestamp()` reduces the
timestamp even when it is not required. Such decrement generates a
negative number in the following calculation within
`drm_update_vblank_count()`:

 u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));

Next, the DIV_ROUND_CLOSEST_ULL macro is invoked using the diff_ns
value, which generates an undefined result. Therefore, the returned
frame is incorrect, which assign a huge number to the variable
frame_end. In this case, causing the loop (`vkms_crc_work_handle()`)
below to take a long time:

 frame_end = drm_crtc_accurate_vblank_count(crtc);
 while (frame_start <= frame_end)
   drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32);

This commit fixes this issue by adding a check that validates whether
the current vblank timestamp is still the same, thus avoiding excessive
timestamp decrement of the  timestamp value.

Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>
Signed-off-by: Shayenne Moura <shayenneluzmoura@...il.com>
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 7508815fac11..3ce60e66673e 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -74,9 +74,13 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
 {
 	struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
 	struct vkms_output *output = &vkmsdev->output;
+	struct drm_vblank_crtc *vblank = &dev->vblank[pipe];

 	*vblank_time = output->vblank_hrtimer.node.expires;

+	if (*vblank_time == vblank->time)
+		return true;
+
 	if (!in_vblank_irq)
 		*vblank_time -= output->period_ns;

-- 
2.21.0

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)