iris: consider bufmgr creation to have failed if `dup`ing of the fd fails

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 <ian.d.romanick@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21568>

diff --git a/src/gallium/drivers/iris/iris_bufmgr.c b/src/gallium/drivers/iris/iris_bufmgr.c
index 8e74b77..4732f80 100644 (file)
--- 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;
 }