linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jianlin Lv <iecedge@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jianlin Lv <Jianlin.Lv@arm.com>,
	bpf@vger.kernel.org, kuba@kernel.org, simon.horman@netronome.com,
	davem@davemloft.net, ast@kernel.org,
	alexei.starovoitov@gmail.com, andrii@kernel.org, kafai@fb.com,
	songliubraving@fb.com, yhs@fb.com, john.fastabend@gmail.com,
	kpsingh@kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, oss-drivers@netronome.com,
	linux-api@vger.kernel.org
Subject: Re: [PATCH bpf-next v2] bpf: Simplify expression for identify bpf mem type
Date: Fri, 19 Mar 2021 09:58:37 +0800	[thread overview]
Message-ID: <CAFA-uR93P=Y6vxeq3426gp4F5apC2smqUJP7vJBjU4R+9ddguw@mail.gmail.com> (raw)
In-Reply-To: <939f6d78-b6f8-b9fc-35b7-e8560a8b020c@iogearbox.net>

On Thu, Mar 18, 2021 at 11:58 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 3/18/21 7:36 AM, Jianlin Lv wrote:
> > Added BPF_LD_ST_SIZE_MASK macro as mask of size modifier that help to
> > reduce the evaluation of expressions in if statements,
> > and remove BPF_SIZE_MASK in netronome driver.
> >
> > Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com>
> > ---
> > v2: Move the bpf_LD_ST_SIZE_MASK macro definition to include/linux/bpf.h
> > ---
> >   drivers/net/ethernet/netronome/nfp/bpf/main.h |  8 +++-----
> >   include/linux/bpf.h                           |  1 +
> >   kernel/bpf/verifier.c                         | 12 ++++--------
> >   3 files changed, 8 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/netronome/nfp/bpf/main.h b/drivers/net/ethernet/netronome/nfp/bpf/main.h
> > index d0e17eebddd9..e90981e69763 100644
> > --- a/drivers/net/ethernet/netronome/nfp/bpf/main.h
> > +++ b/drivers/net/ethernet/netronome/nfp/bpf/main.h
> > @@ -346,8 +346,6 @@ struct nfp_insn_meta {
> >       struct list_head l;
> >   };
> >
> > -#define BPF_SIZE_MASK        0x18
> > -
> >   static inline u8 mbpf_class(const struct nfp_insn_meta *meta)
> >   {
> >       return BPF_CLASS(meta->insn.code);
> > @@ -375,7 +373,7 @@ static inline bool is_mbpf_alu(const struct nfp_insn_meta *meta)
> >
> >   static inline bool is_mbpf_load(const struct nfp_insn_meta *meta)
> >   {
> > -     return (meta->insn.code & ~BPF_SIZE_MASK) == (BPF_LDX | BPF_MEM);
> > +     return (meta->insn.code & ~BPF_LD_ST_SIZE_MASK) == (BPF_LDX | BPF_MEM);
> >   }
> >
> >   static inline bool is_mbpf_jmp32(const struct nfp_insn_meta *meta)
> > @@ -395,7 +393,7 @@ static inline bool is_mbpf_jmp(const struct nfp_insn_meta *meta)
> >
> >   static inline bool is_mbpf_store(const struct nfp_insn_meta *meta)
> >   {
> > -     return (meta->insn.code & ~BPF_SIZE_MASK) == (BPF_STX | BPF_MEM);
> > +     return (meta->insn.code & ~BPF_LD_ST_SIZE_MASK) == (BPF_STX | BPF_MEM);
> >   }
> >
> >   static inline bool is_mbpf_load_pkt(const struct nfp_insn_meta *meta)
> > @@ -430,7 +428,7 @@ static inline bool is_mbpf_classic_store_pkt(const struct nfp_insn_meta *meta)
> >
> >   static inline bool is_mbpf_atomic(const struct nfp_insn_meta *meta)
> >   {
> > -     return (meta->insn.code & ~BPF_SIZE_MASK) == (BPF_STX | BPF_ATOMIC);
> > +     return (meta->insn.code & ~BPF_LD_ST_SIZE_MASK) == (BPF_STX | BPF_ATOMIC);
> >   }
> >
> >   static inline bool is_mbpf_mul(const struct nfp_insn_meta *meta)
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index a25730eaa148..e85924719c65 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -995,6 +995,7 @@ struct bpf_array {
> >                                BPF_F_RDONLY_PROG |    \
> >                                BPF_F_WRONLY |         \
> >                                BPF_F_WRONLY_PROG)
> > +#define BPF_LD_ST_SIZE_MASK  0x18    /* mask of size modifier */
> >
> >   #define BPF_MAP_CAN_READ    BIT(0)
> >   #define BPF_MAP_CAN_WRITE   BIT(1)
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index f9096b049cd6..29fdfdb8abfa 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -11384,15 +11384,11 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
> >       for (i = 0; i < insn_cnt; i++, insn++) {
> >               bpf_convert_ctx_access_t convert_ctx_access;
> >
> > -             if (insn->code == (BPF_LDX | BPF_MEM | BPF_B) ||
> > -                 insn->code == (BPF_LDX | BPF_MEM | BPF_H) ||
> > -                 insn->code == (BPF_LDX | BPF_MEM | BPF_W) ||
> > -                 insn->code == (BPF_LDX | BPF_MEM | BPF_DW))
> > +             /* opcode: BPF_MEM | <size> | BPF_LDX */
> > +             if ((insn->code & ~BPF_LD_ST_SIZE_MASK) == (BPF_LDX | BPF_MEM))
> >                       type = BPF_READ;
> > -             else if (insn->code == (BPF_STX | BPF_MEM | BPF_B) ||
> > -                      insn->code == (BPF_STX | BPF_MEM | BPF_H) ||
> > -                      insn->code == (BPF_STX | BPF_MEM | BPF_W) ||
> > -                      insn->code == (BPF_STX | BPF_MEM | BPF_DW))
> > +             /* opcode: BPF_MEM | <size> | BPF_STX */
> > +             else if ((insn->code & ~BPF_LD_ST_SIZE_MASK) == (BPF_STX | BPF_MEM))
> >                       type = BPF_WRITE;
> >               else
> >                       continue;
> >
>
> To me this cleanup makes the code harder to read, in particular on verfier side,
> I don't think it's worth it, especially given it's not in (highly) performance
> critical code.
>
> Thanks,
> Daniel

I have some different opinions. I think the addition of the mask just helps
developers understand that the currently processed instruction covers all
possible values of size;

In addition, from my experience in reading the verfier.c file,
to fully understand this part of the code, it needs to understand the
meaning of each instruction.
It is really hard to say that this is an easy task, at least for me.
Haha ^_^

Regards,
Jianlin

      reply	other threads:[~2021-03-19  1:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18  6:36 [PATCH bpf-next v2] bpf: Simplify expression for identify bpf mem type Jianlin Lv
2021-03-18 15:58 ` Daniel Borkmann
2021-03-19  1:58   ` Jianlin Lv [this message]

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='CAFA-uR93P=Y6vxeq3426gp4F5apC2smqUJP7vJBjU4R+9ddguw@mail.gmail.com' \
    --to=iecedge@gmail.com \
    --cc=Jianlin.Lv@arm.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=simon.horman@netronome.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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;
as well as URLs for NNTP newsgroup(s).