[trace:latency/for-next 33/38] ERROR: modpost: "__udivdi3" [kernel/trace/rv/rv_monitors_test.ko] undefined!

[trace:latency/for-next 33/38] ERROR: modpost: "__udivdi3" [kernel/trace/rv/rv_monitors_test.ko] undefined!

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace latency/for-next
head:   984b5a36fd12d1849511a45fda32036fe2b0d004
commit: 8da2a88383658dac97769ed8f807ef6100a69480 [33/38] rv: Add KUnit tests for some DA/HA monitors
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20260802/202608020311.hYjqOG5k-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260802/202608020311.hYjqOG5k-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/202608020311.hYjqOG5k-lkp@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "__udivdi3" [kernel/trace/rv/rv_monitors_test.ko] undefined!

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [trace:latency/for-next 33/38] ERROR: modpost: "__udivdi3" [kernel/trace/rv/rv_monitors_test.ko] undefined!

[Nam Cao]

kernel test robot <lkp@intel.com> writes:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace latency/for-next
> head:   984b5a36fd12d1849511a45fda32036fe2b0d004
> commit: 8da2a88383658dac97769ed8f807ef6100a69480 [33/38] rv: Add KUnit tests for some DA/HA monitors
> config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20260802/202608020311.hYjqOG5k-lkp@intel.com/config)
> compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260802/202608020311.hYjqOG5k-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/202608020311.hYjqOG5k-lkp@intel.com/
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
>>> ERROR: modpost: "__udivdi3" [kernel/trace/rv/rv_monitors_test.ko] undefined!

We could switch the division to div64_u64(), or we could change
deadline_thresh's type to u32.

Gabriele, can deadline_thresh fits in u32?

Nam

Re: [trace:latency/for-next 33/38] ERROR: modpost: "__udivdi3" [kernel/trace/rv/rv_monitors_test.ko] undefined!

[Gabriele Monaco]

On Mon, 2026-08-03 at 08:58 +0200, Nam Cao wrote:
> kernel test robot <lkp@intel.com> writes:
> > tree:  
> > https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace latency/fo
> > r-next
> > head:   984b5a36fd12d1849511a45fda32036fe2b0d004
> > commit: 8da2a88383658dac97769ed8f807ef6100a69480 [33/38] rv: Add KUnit tests
> > for some DA/HA monitors
> > config: i386-allmodconfig
> > (https://download.01.org/0day-ci/archive/20260802/202608020311.hYjqOG5k-lkp@
> > intel.com/config)
> > compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
> > reproduce (this is a W=1 build):
> > (https://download.01.org/0day-ci/archive/20260802/202608020311.hYjqOG5k-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/202608020311.hYjqOG5k-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>, old ones prefixed by <<):
> > 
> > > > ERROR: modpost: "__udivdi3" [kernel/trace/rv/rv_monitors_test.ko]
> > > > undefined!
> 
> We could switch the division to div64_u64(), or we could change
> deadline_thresh's type to u32.
> 
> Gabriele, can deadline_thresh fits in u32?

That would make it limited to 4.29 s which is probably way more than enough on
normal systems, but this limit would be driven purely by the KUnit test, I'm not
fond of that.

Probably the best thing here is to use div64_u64() (or even do_div() though we
don't really care about performance).

I can send a quick fix.

Thanks,
Gabriele