linux-kernel - Re: ERROR: modpost: "__divsi3_table" [lib/lz4/lz4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 15 Aug 2022 10:13:40 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     kernel test robot <lkp@...el.com>
Cc:     Arnd Bergmann <arnd@...db.de>, kbuild-all@...ts.01.org,
        linux-kernel@...r.kernel.org,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Kees Cook <keescook@...omium.org>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Sven Schmidt <4sschmid@...ormatik.uni-hamburg.de>
Subject: Re: ERROR: modpost: "__divsi3_table" [lib/lz4/lz4_compress.ko] undefined!

On Mon, Aug 15, 2022 at 4:13 AM kernel test robot <lkp@...el.com> wrote:
>
> Hi Arnd,
>
> First bad commit (maybe != root cause):

(Adding Dinh Nguyen to Cc)

Right, my patch is not the root cause. I see this link failure in lz4
was reported a
couple of times for the combination of nios2 with gcc-11.2:
https://lore.kernel.org/lkml/?q=__divsi3_table

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   568035b01cfb107af8d2e4bd2fb9aea22cf5b868
> commit: 606b102876e3741851dfb09d53f3ee57f650a52c drm: fb_helper: fix CONFIG_FB dependency
> date:   11 months ago
> config: nios2-randconfig-r034-20220814 (https://download.01.org/0day-ci/archive/20220815/202208151050.7pk4KSAG-lkp@intel.com/config)
> compiler: nios2-linux-gcc (GCC) 12.1.0
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=606b102876e3741851dfb09d53f3ee57f650a52c
>         git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>         git fetch --no-tags linus master
>         git checkout 606b102876e3741851dfb09d53f3ee57f650a52c
>         # save the config file
>         mkdir build_dir && cp config build_dir/.config
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=nios2 SHELL=/bin/bash
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp@...el.com>
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> >> ERROR: modpost: "__divsi3_table" [lib/lz4/lz4_compress.ko] undefined!

I analyzed this a while back but mixed up nios2 with xtensa:
https://lore.kernel.org/lkml/CAK8P3a0wboR0evmNGL_VEsNNdLd9x_v8k3APH70t5gfu9D=A6w@mail.gmail.com/

Looking more closely at it now, I see that this was broken by the addition
of the -O3 compiler flag in 4e1a33b105dd ("lib: update LZ4 compressor
module").

We have just removed the option to build the kernel itself with -O3 as
this is known to cause problems. gcc documents a number of options
that are contained in -O3 but not in -O2:

 -fgcse-after-reload -fipa-cp-clone -floop-interchange -floop-unroll-and-jam
 -fpeel-loops -fpredictive-commoning -fsplit-loops -fsplit-paths
 -ftree-loop-distribution -ftree-loop-vectorize -ftree-partial-pre
 -ftree-slp-vectorize -funswitch-loops -fvect-cost-model=dynamic
 -fvect-cost-model=dynamic -fversion-loops-for-strides

If I pass all those options along with -O2, I get the same output
as with -O3, except for the __divsi3_table reference, so we can
probably make it work, but what I don't know is which of the above
options (if any) actually make the object code better.

The upstream lz4 code has the same -O3 flag, so I assume this
was added purely for consistency. Sven Schmidt contributed the
patch that added back -O3, maybe he is interested in doing
some analysis of which of the options we actually want here.

Otherwise I'd suggest we just go with the default kernel flags
that are either -O2 or -Os depending on configuration, as we
do for all other code.

        Arnd