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>
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 */