[xen staging] libxl: get_reaper_lock_and_uid: Document fd handling

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[xen staging] libxl: get_reaper_lock_and_uid: Document fd handling

patchbot
commit 93a62c544e20ba9e141e411bbaae3d65259d13a3
Author:     Ian Jackson <[hidden email]>
AuthorDate: Wed Jan 2 11:59:46 2019 +0000
Commit:     Ian Jackson <[hidden email]>
CommitDate: Fri Jan 11 17:34:26 2019 +0000

    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 <[hidden email]>
    Acked-by: George Dunlap <[hidden email]>
---
 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 20d811be03..b245956b77 100644
--- 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());
--
generated by git-patchbot for /home/xen/git/xen.git#staging

_______________________________________________
Xen-changelog mailing list
[hidden email]
https://lists.xenproject.org/xen-changelog