On Thu, May 18, 2023 at 4:59 PM kernel test robot <lkp@xxxxxxxxx> wrote: > > Hi Andrii, > > kernel test robot noticed the following build warnings: > > [auto build test WARNING on bpf-next/master] > > url: https://github.com/intel-lab-lkp/linux/commits/Andrii-Nakryiko/bpf-support-O_PATH-FDs-in-BPF_OBJ_PIN-and-BPF_OBJ_GET-commands/20230519-060110 > base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master > patch link: https://lore.kernel.org/r/20230518215444.1418789-2-andrii%40kernel.org > patch subject: [PATCH v2 bpf-next 1/3] bpf: support O_PATH FDs in BPF_OBJ_PIN and BPF_OBJ_GET commands > config: m68k-allyesconfig > compiler: m68k-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://github.com/intel-lab-lkp/linux/commit/74f08e59c3fccac04b3c080831615209e11be4fb > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review Andrii-Nakryiko/bpf-support-O_PATH-FDs-in-BPF_OBJ_PIN-and-BPF_OBJ_GET-commands/20230519-060110 > git checkout 74f08e59c3fccac04b3c080831615209e11be4fb > # 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=m68k olddefconfig > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k SHELL=/bin/bash kernel/ > > If you fix the issue, kindly add following tag where applicable > | Reported-by: kernel test robot <lkp@xxxxxxxxx> > | Closes: https://lore.kernel.org/oe-kbuild-all/202305190724.nnh1ZV2F-lkp@xxxxxxxxx/ > > All warnings (new ones prefixed by >>): > > kernel/bpf/syscall.c: In function 'bpf_obj_get': > >> kernel/bpf/syscall.c:2720:13: warning: variable 'path_fd' set but not used [-Wunused-but-set-variable] > 2720 | int path_fd; > | ^~~~~~~ > > > vim +/path_fd +2720 kernel/bpf/syscall.c > > 2717 > 2718 static int bpf_obj_get(const union bpf_attr *attr) > 2719 { > > 2720 int path_fd; > 2721 > 2722 if (CHECK_ATTR(BPF_OBJ) || attr->bpf_fd != 0 || > 2723 attr->file_flags & ~(BPF_OBJ_FLAG_MASK | BPF_F_PATH_FD)) > 2724 return -EINVAL; > 2725 > 2726 /* path_fd has to be accompanied by BPF_F_PATH_FD flag */ > 2727 if (!(attr->file_flags & BPF_F_PATH_FD) && attr->path_fd) > 2728 return -EINVAL; > 2729 > 2730 path_fd = attr->file_flags & BPF_F_PATH_FD ? attr->path_fd : AT_FDCWD; > 2731 return bpf_obj_get_user(attr->path_fd, u64_to_user_ptr(attr->pathname), argh.... s/attr->path_fd/path_fd/ here, but it's curious how tests didn't catch this because we always provide absolute path in attr->pathname, and from openat() man page: If pathname is absolute, then dirfd is ignored. So whatever garbage FD is passed in (in this case 0), the kernel won't complain. Interesting. I'll send v3 with a fix. > 2732 attr->file_flags); > 2733 } > 2734 > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki
