On Wed, 2 Oct 2019 11:05:16 -0300 Rodrigo Siqueira rodrigosiqueiramelo@gmail.com wrote:
For historical reasons, the function drm_wait_vblank_ioctl always return -EINVAL if something gets wrong. This scenario limits the flexibility for the userspace to make detailed verification of any problem and take some action. In particular, the validation of “if (!dev->irq_enabled)” in the drm_wait_vblank_ioctl is responsible for checking if the driver support vblank or not. If the driver does not support VBlank, the function drm_wait_vblank_ioctl returns EINVAL, which does not represent the real issue; this patch changes this behavior by return EOPNOTSUPP. Additionally, drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl, also returns EINVAL if vblank is not supported; this patch also changes the return value to EOPNOTSUPP in these functions. Lastly, these functions are invoked by libdrm, which is used by many compositors; because of this, it is important to check if this change breaks any compositor. In this sense, the following projects were examined:
- Drm-hwcomposer
- Kwin
- Sway
- Wlroots
- Wayland
- Weston
- Mutter
- Xorg (67 different drivers)
For each repository the verification happened in three steps:
- Update the main branch
- Look for any occurrence of "drmCrtcQueueSequence", "drmCrtcGetSequence", and "drmWaitVBlank" with the command git grep -n "STRING".
- Look in the git history of the project with the command
git log -S<STRING>
None of the above projects validate the use of EINVAL when using drmWaitVBlank(), which make safe, at least for these projects, to change the return values. On the other hand, mesa and xserver project uses drmCrtcQueueSequence() and drmCrtcGetSequence(); this change is harmless for both projects.
Change since V5 (Pekka Paalanen):
- Check if the change also affects Mutter
Change since V4 (Daniel):
- Also return EOPNOTSUPP in drm_crtc_[get|queue]_sequence_ioctl
Change since V3:
- Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel)
Change since V2: Daniel Vetter and Chris Wilson
- Replace ENOTTY by EOPNOTSUPP
- Return EINVAL if the parameters are wrong
Cc: Keith Packard keithp@keithp.com Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Chris Wilson chris@chris-wilson.co.uk Cc: Daniel Vetter daniel@ffwll.ch Cc: Pekka Paalanen pekka.paalanen@collabora.com Signed-off-by: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com
drivers/gpu/drm/drm_vblank.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 9c6899758bc9..71cf2633ac58 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -1610,7 +1610,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void *data, unsigned int flags, pipe, high_pipe;
if (!dev->irq_enabled)
return -EINVAL;
return -EOPNOTSUPP;if (vblwait->request.type & _DRM_VBLANK_SIGNAL) return -EINVAL;
Hi,
this part looks safe for Weston indeed, so this part:
Acked-by: Pekka Paalanen pekka.paalanen@collabora.com
There is no need to check the "Wayland" project, it will never do anything with DRM.
(What looks extremely suspicious though is the libdrm implementation of drmWaitVblank() in case the ioctl returns EINTR, but that's unrelated.)
Thanks, pq