linux-kernel - Re: [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMZ6RqLU-Wg0Cau3cM=QsU-t-7Lyzmo1nJ_VAA4Mbw3u0jnNtw@mail.gmail.com>
Date:   Sat, 14 May 2022 14:16:09 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     kernel test robot <lkp@...el.com>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>, llvm@...ts.linux.dev,
        kbuild-all@...ts.01.org, linux-can@...r.kernel.org,
        linux-kernel@...r.kernel.org, Max Staudt <max@...as.org>
Subject: Re: [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and
 can_skb_headroom_valid to skb.c

On Sat. 14 May 2022 à 13:20, kernel test robot <lkp@...el.com> wrote:
> Hi Vincent,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on mkl-can-next/testing]
> [also build test ERROR on v5.18-rc6 next-20220513]
> [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]
>
> url:    https://github.com/intel-lab-lkp/linux/commits/Vincent-Mailhol/can-skb-move-can_dropped_invalid_skb-and-can_skb_headroom_valid-to-skb-c/20220514-003707
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git testing
> config: arm-randconfig-r021-20220512 (https://download.01.org/0day-ci/archive/20220514/202205141221.H0aZXRak-lkp@intel.com/config)
> compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 38189438b69ca27b4c6ce707c52dbd217583d046)
> 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
>         # install arm cross compiling tool for clang build
>         # apt-get install binutils-arm-linux-gnueabi
>         # https://github.com/intel-lab-lkp/linux/commit/8f56e6b1b9945ea47c9f410d1254451df9d6fe22
>         git remote add linux-review https://github.com/intel-lab-lkp/linux
>         git fetch --no-tags linux-review Vincent-Mailhol/can-skb-move-can_dropped_invalid_skb-and-can_skb_headroom_valid-to-skb-c/20220514-003707
>         git checkout 8f56e6b1b9945ea47c9f410d1254451df9d6fe22
>         # save the config file
>         mkdir build_dir && cp config build_dir/.config
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@...el.com>
>
> All errors (new ones prefixed by >>):
>
>    ld.lld: warning: lld uses blx instruction, no object with architecture supporting feature detected
>    ld.lld: warning: lld uses blx instruction, no object with architecture supporting feature detected
> >> ld.lld: error: undefined symbol: can_dropped_invalid_skb
>    >>> referenced by vxcan.c:45 (drivers/net/can/vxcan.c:45)
>    >>>               net/can/vxcan.o:(vxcan_xmit) in archive drivers/built-in.a

OK, so the issue is that VCAN and VXCAN are users of
can_dropped_invalid_skb() but do not depend on CAN_DEV. Above error
will appear if CONFIG_CAN_DEV is not set (or if CONFIG_V{,X}CAN is set
to "yes" and CAN_DEV is set to "module").
I see three choices here:
  1. move can_dropped_invalid_skb() outside of drivers/net/can (i.e.
move it somewhere in net/can).
  2. split CAN_DEV into one additional sub module: CAN_SKB and add a
dependency to it in VCAN and VXCAN.
  3. Add a dependency to CAN_DEV in VCAN and VXCAN

1. is I think the worse, 2. the best, 3. is the laziest option and is
kind of acceptable.
@Marc (and anyone else), what are your thoughts?

Yours sincerely,
Vincent Mailhol