[PATCH] libxl: get_reaper_lock_and_uid: Document fd handling

* [PATCH] libxl: get_reaper_lock_and_uid: Document fd handling
@ 2019-01-02 12:03 Ian Jackson
  2019-01-02 14:02 ` Wei Liu
  2019-01-07 10:42 ` George Dunlap
  0 siblings, 2 replies; 3+ messages in thread
From: Ian Jackson @ 2019-01-02 12:03 UTC (permalink / raw)
  To: xen-devel; +Cc: Wei Liu, Ian Jackson, George Dunlap

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>
---
 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 3+ messages in thread