]> git.ipfire.org Git - thirdparty/kernel/stable.git/commitdiff
dma-buf: fix timeout handling in dma_resv_wait_timeout v2
authorChristian König <christian.koenig@amd.com>
Tue, 28 Jan 2025 09:47:48 +0000 (10:47 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 17 Jul 2025 16:25:04 +0000 (18:25 +0200)
[ Upstream commit 2b95a7db6e0f75587bffddbb490399cbb87e4985 ]

Even the kerneldoc says that with a zero timeout the function should not
wait for anything, but still return 1 to indicate that the fences are
signaled now.

Unfortunately that isn't what was implemented, instead of only returning
1 we also waited for at least one jiffies.

Fix that by adjusting the handling to what the function is actually
documented to do.

v2: improve code readability

Reported-by: Marek Olšák <marek.olsak@amd.com>
Reported-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20250129105841.1806-1-christian.koenig@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/dma-buf/dma-resv.c

index 242a9ec295cf86d770bf4bf8282fafcea9b5c37a..f00ecbaa7868b1e92a3396e1b491d8e3b17d0901 100644 (file)
@@ -558,10 +558,13 @@ retry:
                        goto retry;
                }
 
-               ret = dma_fence_wait_timeout(fence, intr, ret);
+               ret = dma_fence_wait_timeout(fence, intr, timeout);
                dma_fence_put(fence);
                if (ret > 0 && wait_all && (i + 1 < shared_count))
                        goto retry;
+               /* Even for zero timeout the return value is 1 */
+               if (ret > 0 && timeout == 0)
+                       ret = 1;
        }
        return ret;