BPF List
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@google.com>
To: JP Kobryn <inwardvessel@gmail.com>
Cc: bpf@vger.kernel.org, andrii@kernel.org, kernel-team@meta.com
Subject: Re: [PATCH bpf-next] libbpf: synchronize access to print function pointer
Date: Fri, 24 Mar 2023 20:09:53 -0700	[thread overview]
Message-ID: <ZB5mAffV69GUEIZU@google.com> (raw)
In-Reply-To: <20230325010845.46000-1-inwardvessel@gmail.com>

On 03/24, JP Kobryn wrote:
> This patch prevents races on the print function pointer, allowing the
> libbpf_set_print() function to become thread safe.

Why does it have to be thread-safe? The rest of the APIs aren't, so
why can't use solve it on your side by wrapping those calls with a
mutex?

(is there some context I'm missing?)

> Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
> ---
>   tools/lib/bpf/libbpf.c | 9 ++++++---
>   tools/lib/bpf/libbpf.h | 3 +++
>   2 files changed, 9 insertions(+), 3 deletions(-)

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index f6a071db5c6e..15737d7b5a28 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -216,9 +216,10 @@ static libbpf_print_fn_t __libbpf_pr = __base_pr;

>   libbpf_print_fn_t libbpf_set_print(libbpf_print_fn_t fn)
>   {
> -	libbpf_print_fn_t old_print_fn = __libbpf_pr;
> +	libbpf_print_fn_t old_print_fn;
> +
> +	old_print_fn = __atomic_exchange_n(&__libbpf_pr, fn, __ATOMIC_RELAXED);

> -	__libbpf_pr = fn;
>   	return old_print_fn;
>   }

> @@ -227,8 +228,10 @@ void libbpf_print(enum libbpf_print_level level,  
> const char *format, ...)
>   {
>   	va_list args;
>   	int old_errno;
> +	libbpf_print_fn_t print_fn;

> -	if (!__libbpf_pr)
> +	print_fn = __atomic_load_n(&__libbpf_pr, __ATOMIC_RELAXED);
> +	if (!print_fn)
>   		return;

>   	old_errno = errno;
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 1615e55e2e79..4478809ff9ca 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -99,6 +99,9 @@ typedef int (*libbpf_print_fn_t)(enum  
> libbpf_print_level level,
>   /**
>    * @brief **libbpf_set_print()** sets user-provided log callback  
> function to
>    * be used for libbpf warnings and informational messages.
> + *
> + * This function is thread safe.
> + *
>    * @param fn The log print function. If NULL, libbpf won't print  
> anything.
>    * @return Pointer to old print function.
>    */
> --
> 2.39.2


  reply	other threads:[~2023-03-25  3:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-25  1:08 [PATCH bpf-next] libbpf: synchronize access to print function pointer JP Kobryn
2023-03-25  3:09 ` Stanislav Fomichev [this message]
2023-03-27 18:32   ` Andrii Nakryiko
2023-03-27 18:36 ` Andrii Nakryiko
2023-03-27 18:40 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZB5mAffV69GUEIZU@google.com \
    --to=sdf@google.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=inwardvessel@gmail.com \
    --cc=kernel-team@meta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox