Re: [PATCH v2 2/2] btrfs: defrag: allow fine-tuning defrag behavior based on file extent usage

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2024/3/12 00:24, kernel test robot 写道:
> Hi Qu,
>
> kernel test robot noticed the following build errors:

Thanks as usual, the LKP bots are really helpful to detect such 32 bit
division problems.

>
> [auto build test ERROR on kdave/for-next]
> [also build test ERROR on linus/master v6.8 next-20240308]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:    https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-defrag-add-under-utilized-extent-to-defrag-target-list/20240311-141116
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
> patch link:    https://lore.kernel.org/r/d87c011eca11395aafa23cf7ea3ac8c0c8812fe6.1710137066.git.wqu%40suse.com
> patch subject: [PATCH v2 2/2] btrfs: defrag: allow fine-tuning defrag behavior based on file extent usage
> config: m68k-defconfig (https://download.01.org/0day-ci/archive/20240311/202403112159.IQpF7kcT-lkp@intel.com/config)
> compiler: m68k-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240311/202403112159.IQpF7kcT-lkp@intel.com/reproduce)
>
> 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/202403112159.IQpF7kcT-lkp@intel.com/
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>> ERROR: modpost: "__udivdi3" [fs/btrfs/btrfs.ko] undefined!

So it's my new 100 based (aka, percentage) parameter of usage_ratio
triggering the problem:

+       if (em->len < em->orig_block_len * usage_ratio / 100)

Where my previous version goes "/ 65536" and the compiler just change it
to right shift thus no such problem.

Thanks,
Qu

>