Whamcloud - gitweb
LU-11892 hsm: fix memory leak when scheduling HSM requests 23/34123/2
authorAurelien Degremont <degremoa@amazon.com>
Mon, 28 Jan 2019 13:54:14 +0000 (13:54 +0000)
committerOleg Drokin <green@whamcloud.com>
Wed, 6 Feb 2019 06:35:18 +0000 (06:35 +0000)
After creating a big HSM request candidate list, coordinator thread
allocates an update list which is 16 bytes times the number of
candidates files. In some cases, they could be more than 300,000
candidate files and so several MB will be needed.

Memory allocation failure was skipping candidate list freeing
which led to memory leak.

Test-Parameters: trivial testlist=sanity-hsm
Signed-off-by: Aurelien Degremont <degremoa@amazon.com>
Change-Id: Ibb4833f4430cc50cc014f6d14caf0551e0fce161
Reviewed-on: https://review.whamcloud.com/34123
Tested-by: Jenkins
Reviewed-by: Patrick Farrell <pfarrell@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
lustre/mdt/mdt_coordinator.c

index 6795c7d..51708d1 100644 (file)
@@ -722,10 +722,10 @@ static int mdt_coordinator(void *data)
                updates_sz = updates_cnt * sizeof(*updates);
                OBD_ALLOC_LARGE(updates, updates_sz);
                if (updates == NULL) {
-                       CERROR("%s: Cannot allocate memory (%d o) "
-                              "for %d updates\n",
+                       CERROR("%s: Cannot allocate memory (%d bytes) "
+                               "for %d updates. Too many HSM requests?\n",
                               mdt_obd_name(mdt), updates_sz, updates_cnt);
-                       continue;
+                       goto clean_cb_alloc;
                }
 
                /* here hsd contains a list of requests to be started */