linux-kernel - Re: [PATCH 1/1] libbpf: Define MFD

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: Thu, 21 Mar 2024 09:13:35 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Andrii Nakryiko <andrii@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, bpf@...r.kernel.org, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 1/1] libbpf: Define MFD_CLOEXEC if not available

On Thu, Mar 21, 2024 at 9:02 AM Arnaldo Carvalho de Melo
<acme@...nel.org> wrote:
>
> Since its going directly to the syscall to avoid not having
> memfd_create() available in some systems, do the same for its
> MFD_CLOEXEC flags, defining it if not available.
>
> This fixes the build in those systems, noticed while building perf on a
> set of build containers.
>
> Fixes: 9fa5e1a180aa639f ("libbpf: Call memfd_create() syscall directly")
> Cc: Andrii Nakryiko <andrii@...nel.org>
> Cc: Daniel Borkmann <daniel@...earbox.net>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@...hat.com>
> ---
>  tools/lib/bpf/libbpf.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index efab29b8935bd9f7..635a38c6f947a34d 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -1650,6 +1650,10 @@ static int sys_memfd_create(const char *name, unsigned flags)
>         return syscall(__NR_memfd_create, name, flags);
>  }
>
> +#ifndef MFD_CLOEXEC
> +#define MFD_CLOEXEC 0x0001U
> +#endif
> +

makes sense, and lgtm. Do you need it in the bpf or bpf-next tree the
most? your patch header doesn't specify this


>  static int create_placeholder_fd(void)
>  {
>         int fd;
> --
> 2.44.0
>