From 814eb9e2ceae538abbb56ee762074e59b014b3c3 Mon Sep 17 00:00:00 2001 From: Dylan Baker Date: Mon, 27 Feb 2023 10:55:25 -0800 Subject: [PATCH] iris: consider bufmgr creation to have failed if `dup`ing of the fd fails MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Coverity points out that we can pass a negative value to `close()`, which results in an unchecked error. While this is technically true, it really isn't a problem as `close()` is speced to return -1 in that case (which we ignore). However, what is true is that if we fail to dup the fd (the only case where we could end up with a negative value), then we're in an unrecoverable error state anyway, and should go to the error cleanup code. CID: 1521539 Reviewed-by: Ian Romanick Reviewed-by: Marcin Ślusarz Part-of: --- src/gallium/drivers/iris/iris_bufmgr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/iris/iris_bufmgr.c b/src/gallium/drivers/iris/iris_bufmgr.c index 8e74b77..4732f80 100644 --- a/src/gallium/drivers/iris/iris_bufmgr.c +++ b/src/gallium/drivers/iris/iris_bufmgr.c @@ -2396,6 +2396,8 @@ iris_bufmgr_create(struct intel_device_info *devinfo, int fd, bool bo_reuse) * fd so that its namespace does not clash with another. */ bufmgr->fd = os_dupfd_cloexec(fd); + if (bufmgr->fd == -1) + goto error_dup; p_atomic_set(&bufmgr->refcount, 1); @@ -2512,6 +2514,7 @@ error_slabs_init: } error_engine_info: close(bufmgr->fd); +error_dup: free(bufmgr); return NULL; } -- 2.7.4