Re: [PATCH v2 bpf-next 1/3] bpf: support O_PATH FDs in BPF_OBJ_PIN and BPF_OBJ_GET commands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux