From 93a62c544e20ba9e141e411bbaae3d65259d13a3 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Wed, 2 Jan 2019 11:59:46 +0000 Subject: [PATCH] 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 Acked-by: George Dunlap --- 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()); -- 2.39.5