libxl: get_reaper_lock_and_uid: Document fd handling

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@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 20d811be031c3da89df6b87c67f7b8dce74feab6..b245956b7748cede8fd285407c7d411b6c9b00c8 100644 (file)
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -3024,7 +3024,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());