bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Andrii Nakryiko <andriin@fb.com>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>
Cc: "andrii.nakryiko@gmail.com" <andrii.nakryiko@gmail.com>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next] libbpf: simplify BPF_CORE_READ_BITFIELD_PROBED usage
Date: Wed, 6 Nov 2019 21:18:47 +0000	[thread overview]
Message-ID: <bdc51aac-6d39-13a6-f50e-8fca3d329b4b@fb.com> (raw)
In-Reply-To: <20191106201500.2582438-1-andriin@fb.com>



On 11/6/19 12:15 PM, Andrii Nakryiko wrote:
> Streamline BPF_CORE_READ_BITFIELD_PROBED interface to follow
> BPF_CORE_READ_BITFIELD (direct) and BPF_CORE_READ, in general, i.e., just
> return read result or 0, if underlying bpf_probe_read() failed.
> 
> In practice, real applications rarely check bpf_probe_read() result, because
> it has to always work or otherwise it's a bug. So propagating internal
> bpf_probe_read() error from this macro hurts usability without providing real
> benefits in practice. This patch fixes the issue and simplifies usage,
> noticeable even in selftest itself.

Agreed. This will be consistent with direct read where
returning value will be 0 if any fault happens.

In really rare cases, if user want to distinguish good value 0 from
bpf_probe_read() returning error, all building macros are in the header
file, user can have a custom solution. But let us have API work
for common use case with good usability.

> 
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>

Acked-by: Yonghong Song <yhs@fb.com>


> ---
>   tools/lib/bpf/bpf_core_read.h                 | 27 ++++++++-----------
>   .../progs/test_core_reloc_bitfields_probed.c  | 19 +++++--------
>   2 files changed, 18 insertions(+), 28 deletions(-)
> 
> diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h
> index 11461b2623b0..7009dc90e012 100644
> --- a/tools/lib/bpf/bpf_core_read.h
> +++ b/tools/lib/bpf/bpf_core_read.h
> @@ -39,32 +39,27 @@ enum bpf_field_info_kind {
>   #endif
>   
>   /*
> - * Extract bitfield, identified by src->field, and put its value into u64
> - * *res. All this is done in relocatable manner, so bitfield changes such as
> + * Extract bitfield, identified by s->field, and return its value as u64.
> + * All this is done in relocatable manner, so bitfield changes such as
>    * signedness, bit size, offset changes, this will be handled automatically.
>    * This version of macro is using bpf_probe_read() to read underlying integer
>    * storage. Macro functions as an expression and its return type is
>    * bpf_probe_read()'s return value: 0, on success, <0 on error.
>    */
> -#define BPF_CORE_READ_BITFIELD_PROBED(src, field, res) ({		      \
> -	unsigned long long val;						      \
> +#define BPF_CORE_READ_BITFIELD_PROBED(s, field) ({			      \
> +	unsigned long long val = 0;					      \
>   									      \
> -	*res = 0;							      \
> -	val = __CORE_BITFIELD_PROBE_READ(res, src, field);		      \
> -	if (!val) {							      \
> -		*res <<= __CORE_RELO(src, field, LSHIFT_U64);		      \
> -		val = __CORE_RELO(src, field, RSHIFT_U64);		      \
> -		if (__CORE_RELO(src, field, SIGNED))			      \
> -			*res = ((long long)*res) >> val;		      \
> -		else							      \
> -			*res = ((unsigned long long)*res) >> val;	      \
> -		val = 0;						      \
> -	}								      \
> +	__CORE_BITFIELD_PROBE_READ(&val, s, field);			      \
> +	val <<= __CORE_RELO(s, field, LSHIFT_U64);			      \
> +	if (__CORE_RELO(s, field, SIGNED))				      \
> +		val = ((long long)val) >> __CORE_RELO(s, field, RSHIFT_U64);  \
> +	else								      \
> +		val = val >> __CORE_RELO(s, field, RSHIFT_U64);		      \
>   	val;								      \
>   })
>   
>   /*
> - * Extract bitfield, identified by src->field, and return its value as u64.
> + * Extract bitfield, identified by s->field, and return its value as u64.
>    * This version of macro is using direct memory reads and should be used from
>    * BPF program types that support such functionality (e.g., typed raw
>    * tracepoints).
> diff --git a/tools/testing/selftests/bpf/progs/test_core_reloc_bitfields_probed.c b/tools/testing/selftests/bpf/progs/test_core_reloc_bitfields_probed.c
> index a381f8ac2419..e466e3ab7de4 100644
> --- a/tools/testing/selftests/bpf/progs/test_core_reloc_bitfields_probed.c
> +++ b/tools/testing/selftests/bpf/progs/test_core_reloc_bitfields_probed.c
> @@ -37,11 +37,6 @@ struct core_reloc_bitfields_output {
>   	int64_t		s32;
>   };
>   
> -#define TRANSFER_BITFIELD(in, out, field)				\
> -	if (BPF_CORE_READ_BITFIELD_PROBED(in, field, &res))		\
> -		return 1;						\
> -	out->field = res
> -
>   SEC("raw_tracepoint/sys_enter")
>   int test_core_bitfields(void *ctx)
>   {
> @@ -49,13 +44,13 @@ int test_core_bitfields(void *ctx)
>   	struct core_reloc_bitfields_output *out = (void *)&data.out;
>   	uint64_t res;
>   
> -	TRANSFER_BITFIELD(in, out, ub1);
> -	TRANSFER_BITFIELD(in, out, ub2);
> -	TRANSFER_BITFIELD(in, out, ub7);
> -	TRANSFER_BITFIELD(in, out, sb4);
> -	TRANSFER_BITFIELD(in, out, sb20);
> -	TRANSFER_BITFIELD(in, out, u32);
> -	TRANSFER_BITFIELD(in, out, s32);
> +	out->ub1 = BPF_CORE_READ_BITFIELD_PROBED(in, ub1);
> +	out->ub2 = BPF_CORE_READ_BITFIELD_PROBED(in, ub2);
> +	out->ub7 = BPF_CORE_READ_BITFIELD_PROBED(in, ub7);
> +	out->sb4 = BPF_CORE_READ_BITFIELD_PROBED(in, sb4);
> +	out->sb20 = BPF_CORE_READ_BITFIELD_PROBED(in, sb20);
> +	out->u32 = BPF_CORE_READ_BITFIELD_PROBED(in, u32);
> +	out->s32 = BPF_CORE_READ_BITFIELD_PROBED(in, s32);
>   
>   	return 0;
>   }
> 

  reply	other threads:[~2019-11-06 21:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 20:15 [PATCH bpf-next] libbpf: simplify BPF_CORE_READ_BITFIELD_PROBED usage Andrii Nakryiko
2019-11-06 21:18 ` Yonghong Song [this message]
2019-11-06 21:58   ` Alexei Starovoitov
2019-11-06 22:02     ` Yonghong Song

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=bdc51aac-6d39-13a6-f50e-8fca3d329b4b@fb.com \
    --to=yhs@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).