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/[email protected]/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 <[email protected]> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ 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 https://github.com/intel/lkp-tests/wiki
