On Thu, Nov 17, 2022 at 02:21:46PM -0800, coverity-bot wrote: > Hello! > > This is an experimental semi-automated report about issues detected by > Coverity from a scan of next-20221117 as part of the linux-next 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 commits: > > Wed Nov 16 16:19:12 2022 -0800 > 9097e28c25c8 ("mm: add zblock - new allocator for use via zpool API") > > Coverity reported the following: > > *** CID 1527349: Control flow issues (NO_EFFECT) > mm/zblock.c:412 in zblock_reclaim_block() > 406 unsigned long handle, block_type, slot; > 407 int ret, i, reclaimed; > 408 > 409 /* start with list storing blocks with the worst compression and try > 410 * to evict the first added (oldest) block in this list > 411 */ > vvv CID 1527349: Control flow issues (NO_EFFECT) > vvv This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "block_type >= 0UL". > 412 for (block_type = ARRAY_SIZE(block_desc) - 1; block_type >= 0; --block_type) { This seems like a legit issue. -- Gustavo > 413 list = &(pool->block_lists[block_type]); > 414 spin_lock(&list->lock); > 415 > 416 /* find the oldest block in list */ > 417 block = list_last_entry(&list->head, struct zblock_block, block_node); > > 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 these lines (but double-check the "Fixes" first): > > Reported-by: coverity-bot <keescook+coverity-bot@xxxxxxxxxxxx> > Addresses-Coverity-ID: 1527349 ("Control flow issues") > Fixes: 9097e28c25c8 ("mm: add zblock - new allocator for use via zpool API") > > Thanks for your attention! > > -- > Coverity-bot
