Coverity: reclaim_high(): Error handling issues

Hello!

This is an experimental automated report about issues detected by Coverity from a scan of next-20191025 as part of the linux-next weekly scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan

You're getting this email because you were associated with the identified lines of code (noted below) that were touched by recent commits:

f7e1cb6ec51b ("mm: memcontrol: account socket memory in unified hierarchy memory controller")

Coverity reported the following:

*** CID 1487368: Error handling issues (CHECKED_RETURN) /mm/memcontrol.c: 2343 in reclaim_high()

2337     			 gfp_t gfp_mask)
2338     {
2339     	do {
2340     		if (page_counter_read(&memcg->memory) <= memcg->high)
2341     			continue;
2342     		memcg_memory_event(memcg, MEMCG_HIGH);
vvv     CID 1487368:  Error handling issues  (CHECKED_RETURN)
vvv     Calling "try_to_free_mem_cgroup_pages" without checking return value (as is done elsewhere 5 out of 6 times).
2343     		try_to_free_mem_cgroup_pages(memcg, nr_pages, gfp_mask, true);
2344     	} while ((memcg = parent_mem_cgroup(memcg)));
2345     }

2346
2347 static void high_work_func(struct work_struct *work)
2348 {

If this is a false positive, please let us know so we can mark it as such, or teach the Coverity rules to be smarter. If not, please make sure fixes get into linux-next. :) For patches fixing this, please include:

Addresses-Coverity-ID: 1487368 ("Error handling issues")

Thanks for your attention!

Coverity-bot

JFTR This seems misleading wrt to the issue reported here AFAICS. The code was there even before this commit.

Yes we do not check for the return value here because the high limit is a best effort feature. A more highlevel throttling which is not based on the reclaim directly is implemented in mem_cgroup_handle_over_high

Michal Hocko
SUSE Labs