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]
Date:   Tue, 21 Sep 2021 16:20:38 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Muhammad Falak R Wani <falakreyaz@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] libbpf: Use sysconf to simplify libbpf_num_possible_cpus

On Mon, Sep 20, 2021 at 11:04 PM Muhammad Falak R Wani
<falakreyaz@...il.com> wrote:
>
> Simplify libbpf_num_possible_cpus by using sysconf(_SC_NPROCESSORS_CONF)
> instead of parsing a file.
> This patch is a part of libbpf-1.0 milestone.
>
> Reference: https://github.com/libbpf/libbpf/issue/383

I've been asking people to use a reference style like this, so that we
don't confuse this with proper Linux tags. It's also useful to use
"Closes: " keyword to let Github auto-close the issue when this patch
eventually is synced into Github. So in this case I'd phrase
everything as:

"This patch is a part ([0]) of libbpf-1.0 milestone.

  [0] Closes: https://github.com/libbpf/libbpf/issue/383

Please update in the next revision.


Also, keep in mind that we ask to use "[PATCH bpf-next]" prefix when
submitting patches against the bpf-next kernel tree. It makes the
intent clear and our BPF CI system knows which tree to test against.
Thanks.

>
> Signed-off-by: Muhammad Falak R Wani <falakreyaz@...il.com>
> ---
>  tools/lib/bpf/libbpf.c | 16 +++-------------
>  1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index da65a1666a5e..1d730b08ee44 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -10765,25 +10765,15 @@ int parse_cpu_mask_file(const char *fcpu, bool **mask, int *mask_sz)
>
>  int libbpf_num_possible_cpus(void)
>  {
> -       static const char *fcpu = "/sys/devices/system/cpu/possible";
>         static int cpus;
> -       int err, n, i, tmp_cpus;
> -       bool *mask;
> +       int tmp_cpus;
>
>         tmp_cpus = READ_ONCE(cpus);
>         if (tmp_cpus > 0)
>                 return tmp_cpus;
>
> -       err = parse_cpu_mask_file(fcpu, &mask, &n);
> -       if (err)
> -               return libbpf_err(err);
> -
> -       tmp_cpus = 0;
> -       for (i = 0; i < n; i++) {
> -               if (mask[i])
> -                       tmp_cpus++;
> -       }
> -       free(mask);
> +       tmp_cpus = sysconf(_SC_NPROCESSORS_CONF);
> +       /* sysconf sets errno; no need to use libbpf_err */

I'd say it's still a good idea for explicitness and to show that we
didn't forget about it :) Plus, if it actually ever fails, we don't
want to WRITE_ONCE() here, so please follow the same error handling
logic as it was previously with parse_cpu_mask_file.

>
>         WRITE_ONCE(cpus, tmp_cpus);
>         return tmp_cpus;
> --
> 2.17.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ