event API conformance testing with coccinelle spatches are being used to locate API usage inconsistencies this triggert with: ./drivers/gpu/drm/armada/armada_overlay.c:153 incorrect check for negative return
Return type of wait_event_timeout is signed long not int and the return type is >=0 always thus the negative check was effectively ignoring the timeout event - this looks like a bug. An appropriately named variable of type long is inserted and the call fixed up as well as the negative return check changed to detect the timeout event.
Signed-off-by: Nicholas Mc Guire hofrat@osadl.org ---
The calling side seems to assume 0 as success and <0 as error so returning -ETIME should be fine here.
Patch was compile tested with imx_v6_v7_defconfig + CONFIG_DRM_ARMADA=m
Patch is against 4.1-rc7 (localversion-next is -next-20150609)
drivers/gpu/drm/armada/armada_overlay.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c b/drivers/gpu/drm/armada/armada_overlay.c index c5b06fd..f308949 100644 --- a/drivers/gpu/drm/armada/armada_overlay.c +++ b/drivers/gpu/drm/armada/armada_overlay.c @@ -107,7 +107,7 @@ armada_plane_update(struct drm_plane *plane, struct drm_crtc *crtc, struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc); uint32_t val, ctrl0; unsigned idx = 0; - int ret; + long time_left;
crtc_w = armada_limit(crtc_x, crtc_w, dcrtc->crtc.mode.hdisplay); crtc_h = armada_limit(crtc_y, crtc_h, dcrtc->crtc.mode.vdisplay); @@ -150,11 +150,11 @@ armada_plane_update(struct drm_plane *plane, struct drm_crtc *crtc, dcrtc->base + LCD_SPU_SRAM_PARA1); }
- ret = wait_event_timeout(dplane->vbl.wait, - list_empty(&dplane->vbl.update.node), - HZ/25); - if (ret < 0) - return ret; + time_left = wait_event_timeout(dplane->vbl.wait, + list_empty(&dplane->vbl.update.node), + HZ / 25); + if (time_left == 0) + return -ETIME;
if (plane->fb != fb) { struct armada_gem_object *obj = drm_fb_obj(fb);
On Wed, Jun 10, 2015 at 01:07:08PM +0200, Nicholas Mc Guire wrote:
The calling side seems to assume 0 as success and <0 as error so returning -ETIME should be fine here.
The idea here is to allow the remainder of the code to execute when the condition succeeds _or_ times out. If it times out, that is not a failure - it merely means that the display has been blanked and we're not seeing frame done interrupts anymore.
The code should not be checking the returned value at all - in fact I have updates to this code which (in part) remove this, and fix a glaring problem that the wait queue is never woken.
I wonder how many places you've made this same mistake... please ensure that you review the code you're changing carefully.
On Wed, 10 Jun 2015, Russell King - ARM Linux wrote:
On Wed, Jun 10, 2015 at 01:07:08PM +0200, Nicholas Mc Guire wrote:
The calling side seems to assume 0 as success and <0 as error so returning -ETIME should be fine here.
The idea here is to allow the remainder of the code to execute when the condition succeeds _or_ times out. If it times out, that is not a failure - it merely means that the display has been blanked and we're not seeing frame done interrupts anymore.
The code should not be checking the returned value at all - in fact I have updates to this code which (in part) remove this, and fix a glaring problem that the wait queue is never woken.
I wonder how many places you've made this same mistake... please ensure that you review the code you're changing carefully.
Sorry for that - I do try my best to understand the code - my obviously wrong understanding of the code was that a negative return was being expected as being possible and then handed back to the caller so I assumed that would be the timeout case - but as this can never happen it was basically ignoring the timeout - that the execution should continue in the case of timeout being reached was not clear to me (it might be worth a comment ?)
I did find similar cases in other drivers ./drivers/media/platform/s5p-tv/mixer_reg.c:364 incorrect check for negative return checking for < 0 and returning (so unreachable return statement with no effect but no side-effect in that condition ither) or ./drivers/media/pci/ddbridge/ddbridge-core.c:89 incorrect check for negative return which checked for <= 0 and was fixed up to == 0 which is correct as the < 0 case simply is unreachable - so no change of error handling logic.
but those two other cases I think are correctly fixed up.
thx! hofrat
dri-devel@lists.freedesktop.org
-
Nicholas Mc Guire -
Nicholas Mc Guire -
Russell King - ARM Linux