[Xen-devel] [PATCH] libxl: get_reaper_lock_and_uid: Document fd handling

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Coverity understandably complains that get_reaper_lock_and_uid leaks
the fd and hence open-file.  But this is intentional: the lock becomes
owned by the child process as a whole, which is entirely the property
of libxl.

(The coding style here in this subprocess is a bit anomalous but it's
probably not worth it to convert get_reaper_lock_and_uid to `goto out'
style and have it explicitly return the fd number.)

Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
---
 tools/libxl/libxl_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index be493cf9f2..5de3fc7a67 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2889,7 +2889,7 @@ static int 
get_reaper_lock_and_uid(libxl__destroy_devicemodel_state *ddms,
     int domid = ddms->domid;
     int r;
     const char * lockfile;
-    int fd;
+    int fd; /* "leaked" into the general process context (even on failure) */
 
     /* Try to lock the "reaper uid" */
     lockfile = GCSPRINTF("%s/dm-reaper-lock", libxl__run_dir_path());
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel