netdev - Re: [PATCH 16/39] convert __bpf_prog

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAEf4BzasCg8o2qc14kYkChT78jdkVsYXhGW3zUWjhmoAgDkkKw@mail.gmail.com>
Date: Tue, 6 Aug 2024 14:08:26 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: viro@...nel.org
Cc: linux-fsdevel@...r.kernel.org, amir73il@...il.com, bpf@...r.kernel.org, 
	brauner@...nel.org, cgroups@...r.kernel.org, kvm@...r.kernel.org, 
	netdev@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 16/39] convert __bpf_prog_get() to CLASS(fd, ...)

On Mon, Jul 29, 2024 at 10:19 PM <viro@...nel.org> wrote:
>
> From: Al Viro <viro@...iv.linux.org.uk>
>
> Irregularity here is fdput() not in the same scope as fdget();
> just fold ____bpf_prog_get() into its (only) caller and that's
> it...
>
> Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
> ---
>  kernel/bpf/syscall.c | 32 +++++++++++---------------------
>  1 file changed, 11 insertions(+), 21 deletions(-)
>

Folding makes total sense, the logic lgtm (though I find CLASS(fd,
f)(ufd) utterly non-intuitive naming-wise). Extra IS_ERR(prog) check
should be dropped though, see below.

Acked-by: Andrii Nakryiko <andrii@...nel.org>

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 3093bf2cc266..c5b252c0faa8 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2407,18 +2407,6 @@ int bpf_prog_new_fd(struct bpf_prog *prog)
>                                 O_RDWR | O_CLOEXEC);
>  }
>
> -static struct bpf_prog *____bpf_prog_get(struct fd f)
> -{
> -       if (!fd_file(f))
> -               return ERR_PTR(-EBADF);
> -       if (fd_file(f)->f_op != &bpf_prog_fops) {
> -               fdput(f);
> -               return ERR_PTR(-EINVAL);
> -       }
> -
> -       return fd_file(f)->private_data;
> -}
> -
>  void bpf_prog_add(struct bpf_prog *prog, int i)
>  {
>         atomic64_add(i, &prog->aux->refcnt);
> @@ -2474,20 +2462,22 @@ bool bpf_prog_get_ok(struct bpf_prog *prog,
>  static struct bpf_prog *__bpf_prog_get(u32 ufd, enum bpf_prog_type *attach_type,
>                                        bool attach_drv)
>  {
> -       struct fd f = fdget(ufd);
> +       CLASS(fd, f)(ufd);
>         struct bpf_prog *prog;
>
> -       prog = ____bpf_prog_get(f);
> -       if (IS_ERR(prog))
> +       if (fd_empty(f))
> +               return ERR_PTR(-EBADF);
> +       if (fd_file(f)->f_op != &bpf_prog_fops)
> +               return ERR_PTR(-EINVAL);
> +
> +       prog = fd_file(f)->private_data;
> +       if (IS_ERR(prog))       // can that actually happen?

no, it can't, private_data will always be a valid pointer, otherwise
that file would never be successfully created

>                 return prog;
> -       if (!bpf_prog_get_ok(prog, attach_type, attach_drv)) {
> -               prog = ERR_PTR(-EINVAL);
> -               goto out;
> -       }
> +
> +       if (!bpf_prog_get_ok(prog, attach_type, attach_drv))
> +               return ERR_PTR(-EINVAL);
>
>         bpf_prog_inc(prog);
> -out:
> -       fdput(f);
>         return prog;
>  }
>
> --
> 2.39.2
>
>