On Tue, Jun 8, 2021 at 11:05 AM coverity-bot <keescook@xxxxxxxxxxxx> wrote:
>
> You're getting this email because you were associated with the identified
> lines of code (noted below) that were touched by commits:
>
> Tue Dec 15 12:13:39 2020 -0800
> 013339df116c ("mm/rmap: always do TTU_IGNORE_ACCESS")
Heh. Entirely independent change, but whatever..
That does mean that the suggested
> Fixes: 013339df116c ("mm/rmap: always do TTU_IGNORE_ACCESS")
tag would have been entirely bogus. That commit didn't actually change
the coverity issue in question anyway, it just happened to change that
line in other ways.
Maybe the coverity-bot logic could actually try to see if a coverity
report changes, which it wouldn't have done here.
The report itself is:
> 1421 if (page_mapped(page))
> vvv CID 1505146: Error handling issues (CHECKED_RETURN)
> vvv Calling "try_to_unmap" without checking return value (as is done elsewhere 4 out of 5 times).
> 1422 try_to_unmap(page, TTU_IGNORE_MLOCK);
Hmm. That "4 out of 5 times" seems misleading. It implies that 80% of
callers check the return value.
But when I actually grep for it, I see 4 call-sites that don't check
the return value, and 5 that do. So it's more like 55% of callers that
do check.
Anyway, this is a false positive. You don't have to check the return
value. The main example of doing so is the page-out code in
mm/vmscan.c, and it does so just to keep track of success/fail
statistics.
Linus
