Re: [PATCH v3 3/3] overflow: Remove is_non_negative() and is_negative()

kernel test robot
2025-12-22T19:55:27Z

Hi Vincent,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 3e7f562e20ee87a25e104ef4fce557d39d62fa85]

url: https://github.com/intel-lab-lkp/linux/commits/Vincent-Mailhol/kbuild-remove-gcc-s-Wtype-limits/20251220-190509
base: 3e7f562e20ee87a25e104ef4fce557d39d62fa85
patch link: https://lore.kernel.org/r/20251220-remove_wtype-limits-v3-3-24b170af700e%40kernel.org
patch subject: [PATCH v3 3/3] overflow: Remove is_non_negative() and is_negative()
config: i386-randconfig-141-20251222 (https://download.01.org/0day-ci/archive/20251223/202512230342.Lgha2HGH-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512230342.Lgha2HGH-lkp@intel.com/

New smatch warnings:
block/blk-settings.c:702 blk_stack_atomic_writes_chunk_sectors() warn: unsigned '*_d' is never less than zero.
block/blk-settings.c:702 blk_stack_atomic_writes_chunk_sectors() warn: unsigned '_a' is never less than zero.
drivers/nvme/host/core.c:3353 nvme_mps_to_sectors() warn: unsigned '*_d' is never less than zero.
drivers/nvme/host/core.c:3353 nvme_mps_to_sectors() warn: unsigned '_a' is never less than zero.

Old smatch warnings:
drivers/nvme/host/core.c:5032 nvme_free_cels() warn: iterator 'i' not incremented

vim +702 block/blk-settings.c

d7f36dc446e894 John Garry 2024-11-18 689
63d092d1c1b1f7 John Garry 2025-07-11 690 static void blk_stack_atomic_writes_chunk_sectors(struct queue_limits *t)
d7f36dc446e894 John Garry 2024-11-18 691 {
63d092d1c1b1f7 John Garry 2025-07-11 692 unsigned int chunk_bytes;
d7f36dc446e894 John Garry 2024-11-18 693
63d092d1c1b1f7 John Garry 2025-07-11 694 if (!t->chunk_sectors)
63d092d1c1b1f7 John Garry 2025-07-11 695 return;
63d092d1c1b1f7 John Garry 2025-07-11 696
63d092d1c1b1f7 John Garry 2025-07-11 697 /*
63d092d1c1b1f7 John Garry 2025-07-11 698 * If chunk sectors is so large that its value in bytes overflows
63d092d1c1b1f7 John Garry 2025-07-11 699 * UINT_MAX, then just shift it down so it definitely will fit.
63d092d1c1b1f7 John Garry 2025-07-11 700 * We don't support atomic writes of such a large size anyway.
63d092d1c1b1f7 John Garry 2025-07-11 701 */
63d092d1c1b1f7 John Garry 2025-07-11 @702 if (check_shl_overflow(t->chunk_sectors, SECTOR_SHIFT, &chunk_bytes))
63d092d1c1b1f7 John Garry 2025-07-11 703 chunk_bytes = t->chunk_sectors;
d7f36dc446e894 John Garry 2024-11-18 704
d7f36dc446e894 John Garry 2024-11-18 705 /*
d7f36dc446e894 John Garry 2024-11-18 706 * Find values for limits which work for chunk size.
d7f36dc446e894 John Garry 2024-11-18 707 * b->atomic_write_hw_unit_{min, max} may not be aligned with chunk
63d092d1c1b1f7 John Garry 2025-07-11 708 * size, as the chunk size is not restricted to a power-of-2.
d7f36dc446e894 John Garry 2024-11-18 709 * So we need to find highest power-of-2 which works for the chunk
d7f36dc446e894 John Garry 2024-11-18 710 * size.
63d092d1c1b1f7 John Garry 2025-07-11 711 * As an example scenario, we could have t->unit_max = 16K and
63d092d1c1b1f7 John Garry 2025-07-11 712 * t->chunk_sectors = 24KB. For this case, reduce t->unit_max to a
63d092d1c1b1f7 John Garry 2025-07-11 713 * value aligned with both limits, i.e. 8K in this example.
d7f36dc446e894 John Garry 2024-11-18 714 */
63d092d1c1b1f7 John Garry 2025-07-11 715 t->atomic_write_hw_unit_max = min(t->atomic_write_hw_unit_max,
63d092d1c1b1f7 John Garry 2025-07-11 716 max_pow_of_two_factor(chunk_bytes));
d7f36dc446e894 John Garry 2024-11-18 717
63d092d1c1b1f7 John Garry 2025-07-11 718 t->atomic_write_hw_unit_min = min(t->atomic_write_hw_unit_min,
d7f36dc446e894 John Garry 2024-11-18 719 t->atomic_write_hw_unit_max);
63d092d1c1b1f7 John Garry 2025-07-11 720 t->atomic_write_hw_max = min(t->atomic_write_hw_max, chunk_bytes);
63d092d1c1b1f7 John Garry 2025-07-11 721 }
d7f36dc446e894 John Garry 2024-11-18 722

--
0-DAY CI Kernel Test Service