On Thu, May 18, 2023 at 5:19 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > 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. because other tests have an absolute path to bpf objs?
