bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>, Martin Lau <kafai@fb.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	David Miller <davem@davemloft.net>,
	"Kernel Team" <Kernel-team@fb.com>,
	Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 04/11] bpf: Support bitfield read access in btf_struct_access
Date: Mon, 23 Dec 2019 21:21:58 +0000	[thread overview]
Message-ID: <0ce336dc-203c-f2f0-a877-24360d02452d@fb.com> (raw)
In-Reply-To: <CAEf4Bzam8yp9ciDDY0jye+zE1jM-sbe1+LSjby9ChRvWbeXmbw@mail.gmail.com>



On 12/23/19 12:05 PM, Andrii Nakryiko wrote:
> On Fri, Dec 20, 2019 at 10:26 PM Martin KaFai Lau <kafai@fb.com> wrote:
>>
>> This patch allows bitfield access as a scalar.
>>
>> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
>> ---
>>   kernel/bpf/btf.c | 10 ++++++----
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index 6e652643849b..da73b63acfc5 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>> @@ -3744,10 +3744,6 @@ int btf_struct_access(struct bpf_verifier_log *log,
>>          }
>>
>>          for_each_member(i, t, member) {
>> -               if (btf_member_bitfield_size(t, member))
>> -                       /* bitfields are not supported yet */
>> -                       continue;
>> -
>>                  /* offset of the field in bytes */
>>                  moff = btf_member_bit_offset(t, member) / 8;
>>                  if (off + size <= moff)
>> @@ -3757,6 +3753,12 @@ int btf_struct_access(struct bpf_verifier_log *log,
>>                  if (off < moff)
>>                          continue;
>>
>> +               if (btf_member_bitfield_size(t, member)) {
>> +                       if (off == moff && off + size <= t->size)
>> +                               return SCALAR_VALUE;
>> +                       continue;
>> +               }
> 
> Shouldn't this check be done before (off < moff) above?
> 
> Imagine this situation:
> 
> struct {
>    int :16;
>    int x:8;
> };

Oh, yes, forgot the case where the first bitfield member may have no
name, in which case, `off` will not match any `moff`.

btf_struct_access is used to check vmlinux btf types. I think in
vmlinux we may not have such scenarios. So the above code should
handle vmlinux use cases properly.

But I agree with Andrii that we probably want to handle
anonymous bitfield member (which is ignored in debuginfo and BTF) properly.

> 
> Compiler will generate 4-byte load with offset 0, and then bit shifts
> to extract third byte. From kernel perspective, you'll see that off=0,
> but moff=2, which will get skipped.
> 
> So there are two problems, I think:
> 1. if member is bitfield, special handle that before (off < moff) case.
> 2. off == moff is too precise, I think it should be `off <= moff`, but
> also check that it covers entire bitfield, e.g.:
> 
>    (off + size) * 8 >= btf_member_bit_offset(t, member) +
> btf_member_bitfield_size(t, member)
> 
> Make sense or am I missing anything?
> 
>> +
>>                  /* type of the field */
>>                  mtype = btf_type_by_id(btf_vmlinux, member->type);
>>                  mname = __btf_name_by_offset(btf_vmlinux, member->name_off);
>> --
>> 2.17.1
>>

  reply	other threads:[~2019-12-23 21:22 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-21  6:25 [PATCH bpf-next v2 00/11] Introduce BPF STRUCT_OPS Martin KaFai Lau
2019-12-21  6:25 ` [PATCH bpf-next v2 01/11] bpf: Save PTR_TO_BTF_ID register state when spilling to stack Martin KaFai Lau
2019-12-21  6:25 ` [PATCH bpf-next v2 02/11] bpf: Avoid storing modifier to info->btf_id Martin KaFai Lau
2019-12-21  6:26 ` [PATCH bpf-next v2 03/11] bpf: Add enum support to btf_ctx_access() Martin KaFai Lau
2019-12-21  6:26 ` [PATCH bpf-next v2 04/11] bpf: Support bitfield read access in btf_struct_access Martin KaFai Lau
2019-12-23  7:49   ` Yonghong Song
2019-12-23 20:05   ` Andrii Nakryiko
2019-12-23 21:21     ` Yonghong Song [this message]
2019-12-21  6:26 ` [PATCH bpf-next v2 05/11] bpf: Introduce BPF_PROG_TYPE_STRUCT_OPS Martin KaFai Lau
2019-12-23 19:33   ` Yonghong Song
2019-12-23 20:29   ` Andrii Nakryiko
2019-12-23 22:29     ` Martin Lau
2019-12-23 22:55       ` Andrii Nakryiko
2019-12-24 11:46   ` kbuild test robot
2019-12-21  6:26 ` [PATCH bpf-next v2 06/11] bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS Martin KaFai Lau
2019-12-23 19:57   ` Yonghong Song
2019-12-23 21:44     ` Andrii Nakryiko
2019-12-23 22:15       ` Martin Lau
2019-12-27  6:16     ` Martin Lau
2019-12-23 23:05   ` Andrii Nakryiko
2019-12-28  1:47     ` Martin Lau
2019-12-28  2:24       ` Andrii Nakryiko
2019-12-28  5:16         ` Martin Lau
2019-12-24 12:28   ` kbuild test robot
2019-12-21  6:26 ` [PATCH bpf-next v2 07/11] bpf: tcp: Support tcp_congestion_ops in bpf Martin KaFai Lau
2019-12-23 20:18   ` Yonghong Song
2019-12-23 23:20   ` Andrii Nakryiko
2019-12-24  7:16   ` kbuild test robot
2019-12-24 13:06   ` kbuild test robot
2019-12-21  6:26 ` [PATCH bpf-next v2 08/11] bpf: Add BPF_FUNC_tcp_send_ack helper Martin KaFai Lau
2019-12-21  6:26 ` [PATCH bpf-next v2 09/11] bpf: Synch uapi bpf.h to tools/ Martin KaFai Lau
2019-12-21  6:26 ` [PATCH bpf-next v2 10/11] bpf: libbpf: Add STRUCT_OPS support Martin KaFai Lau
2019-12-23 19:54   ` Andrii Nakryiko
2019-12-26 22:47     ` Martin Lau
2019-12-21  6:26 ` [PATCH bpf-next v2 11/11] bpf: Add bpf_dctcp example Martin KaFai Lau
2019-12-23 23:26   ` Andrii Nakryiko
2019-12-24  1:31     ` Martin Lau
2019-12-24  7:01       ` Andrii Nakryiko
2019-12-24  7:32         ` Martin Lau
2019-12-24 16:50         ` Martin Lau
2019-12-26 19:02           ` Andrii Nakryiko
2019-12-26 20:25             ` Martin Lau
2019-12-26 20:48               ` Andrii Nakryiko
2019-12-26 22:20                 ` Martin Lau
2019-12-26 22:25                   ` Andrii Nakryiko

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=0ce336dc-203c-f2f0-a877-24360d02452d@fb.com \
    --to=yhs@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kafai@fb.com \
    --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).