All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Sitnicki <jakub@cloudflare.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
	kernel-team <kernel-team@cloudflare.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH bpf-next v3 01/16] bpf, netns: Handle multiple link attachments
Date: Thu, 09 Jul 2020 14:49:46 +0200	[thread overview]
Message-ID: <87k0zcam51.fsf@cloudflare.com> (raw)
In-Reply-To: <CAEf4Bzby9pxaaadTAfuvBER1UnaksS3ajpE6SB79L+g3j_YdAg@mail.gmail.com>

On Thu, Jul 09, 2020 at 05:44 AM CEST, Andrii Nakryiko wrote:
> On Thu, Jul 2, 2020 at 2:24 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>>
>> Extend the BPF netns link callbacks to rebuild (grow/shrink) or update the
>> prog_array at given position when link gets attached/updated/released.
>>
>> This let's us lift the limit of having just one link attached for the new
>> attach type introduced by subsequent patch.
>>
>> No functional changes intended.
>>
>> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
>> ---
>>
>> Notes:
>>     v3:
>>     - New in v3 to support multi-prog attachments. (Alexei)
>>
>>  include/linux/bpf.h        |  4 ++
>>  kernel/bpf/core.c          | 22 ++++++++++
>>  kernel/bpf/net_namespace.c | 88 +++++++++++++++++++++++++++++++++++---
>>  3 files changed, 107 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 3d2ade703a35..26bc70533db0 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -928,6 +928,10 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array *progs,
>>
>>  void bpf_prog_array_delete_safe(struct bpf_prog_array *progs,
>>                                 struct bpf_prog *old_prog);
>> +void bpf_prog_array_delete_safe_at(struct bpf_prog_array *array,
>> +                                  unsigned int index);
>> +void bpf_prog_array_update_at(struct bpf_prog_array *array, unsigned int index,
>> +                             struct bpf_prog *prog);
>>  int bpf_prog_array_copy_info(struct bpf_prog_array *array,
>>                              u32 *prog_ids, u32 request_cnt,
>>                              u32 *prog_cnt);
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 9df4cc9a2907..d4b3b9ee6bf1 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -1958,6 +1958,28 @@ void bpf_prog_array_delete_safe(struct bpf_prog_array *array,
>>                 }
>>  }
>>
>> +void bpf_prog_array_delete_safe_at(struct bpf_prog_array *array,
>> +                                  unsigned int index)
>> +{
>> +       bpf_prog_array_update_at(array, index, &dummy_bpf_prog.prog);
>> +}
>> +
>> +void bpf_prog_array_update_at(struct bpf_prog_array *array, unsigned int index,
>> +                             struct bpf_prog *prog)
>
> it's a good idea to mention it in a comment for both delete_safe_at
> and update_at that slots with dummy entries are ignored.

I agree. These two need doc comments. update_at doesn't event hint that
this is not a regular update operation. Will add in v4.

>
> Also, given that index can be out of bounds, should these functions
> actually return error if the slot is not found?

That won't hurt. I mean, from bpf-netns PoV getting such an error would
indicate that there is a bug in the code that manages prog_array. But
perhaps other future users of this new prog_array API can benefit.

>
>> +{
>> +       struct bpf_prog_array_item *item;
>> +
>> +       for (item = array->items; item->prog; item++) {
>> +               if (item->prog == &dummy_bpf_prog.prog)
>> +                       continue;
>> +               if (!index) {
>> +                       WRITE_ONCE(item->prog, prog);
>> +                       break;
>> +               }
>> +               index--;
>> +       }
>> +}
>> +
>>  int bpf_prog_array_copy(struct bpf_prog_array *old_array,
>>                         struct bpf_prog *exclude_prog,
>>                         struct bpf_prog *include_prog,
>> diff --git a/kernel/bpf/net_namespace.c b/kernel/bpf/net_namespace.c
>> index 247543380fa6..6011122c35b6 100644
>> --- a/kernel/bpf/net_namespace.c
>> +++ b/kernel/bpf/net_namespace.c
>> @@ -36,11 +36,51 @@ static void netns_bpf_run_array_detach(struct net *net,
>>         bpf_prog_array_free(run_array);
>>  }
>>
>> +static unsigned int link_index(struct net *net,
>> +                              enum netns_bpf_attach_type type,
>> +                              struct bpf_netns_link *link)
>> +{
>> +       struct bpf_netns_link *pos;
>> +       unsigned int i = 0;
>> +
>> +       list_for_each_entry(pos, &net->bpf.links[type], node) {
>> +               if (pos == link)
>> +                       return i;
>> +               i++;
>> +       }
>> +       return UINT_MAX;
>
> Why not return a negative error, if the slot is not found? Feels a bit
> unusual as far as error reporting goes.

Returning uint played well with the consumer of link_index() return
value, that is bpf_prog_array_update_at(). update at takes an index into
the array, which must not be negative.

But I don't have strong feelings toward it. Will switch to -ENOENT in
v4.

>
>> +}
>> +
>
> [...]

  reply	other threads:[~2020-07-09 12:49 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02  9:24 [PATCH bpf-next v3 00/16] Run a BPF program on socket lookup Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 01/16] bpf, netns: Handle multiple link attachments Jakub Sitnicki
2020-07-09  3:44   ` Andrii Nakryiko
2020-07-09 12:49     ` Jakub Sitnicki [this message]
2020-07-09 22:02       ` Andrii Nakryiko
2020-07-10 19:23         ` Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 02/16] bpf: Introduce SK_LOOKUP program type with a dedicated attach point Jakub Sitnicki
2020-07-04 18:42   ` Yonghong Song
2020-07-06 11:44     ` Jakub Sitnicki
2020-07-05  9:20   ` kernel test robot
2020-07-05  9:20     ` kernel test robot
2020-07-05  9:20   ` [RFC PATCH] bpf: sk_lookup_prog_ops can be static kernel test robot
2020-07-05  9:20     ` kernel test robot
2020-07-07  9:21   ` [PATCH bpf-next v3 02/16] bpf: Introduce SK_LOOKUP program type with a dedicated attach point Jakub Sitnicki
2020-07-09  4:08   ` Andrii Nakryiko
2020-07-09 13:25     ` Jakub Sitnicki
2020-07-09 23:09       ` Andrii Nakryiko
2020-07-10  8:55         ` Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 03/16] inet: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 04/16] inet: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-02 10:27   ` Lorenz Bauer
2020-07-02 12:46     ` Jakub Sitnicki
2020-07-02 13:19       ` Lorenz Bauer
2020-07-06 11:24         ` Jakub Sitnicki
2020-07-06 12:06   ` Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 05/16] inet6: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 06/16] inet6: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 07/16] udp: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 08/16] udp: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 09/16] udp6: Extract helper for selecting socket from reuseport group Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 10/16] udp6: Run SK_LOOKUP BPF program on socket lookup Jakub Sitnicki
2020-07-02 14:51   ` kernel test robot
2020-07-02 14:51     ` kernel test robot
2020-07-03 13:04     ` Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 11/16] bpf: Sync linux/bpf.h to tools/ Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 12/16] libbpf: Add support for SK_LOOKUP program type Jakub Sitnicki
2020-07-09  4:23   ` Andrii Nakryiko
2020-07-09 15:51     ` Jakub Sitnicki
2020-07-09 23:13       ` Andrii Nakryiko
2020-07-10  8:37         ` Jakub Sitnicki
2020-07-10 18:55           ` Andrii Nakryiko
2020-07-10 19:24             ` Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 13/16] tools/bpftool: Add name mappings for SK_LOOKUP prog and attach type Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 14/16] selftests/bpf: Add verifier tests for bpf_sk_lookup context access Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 15/16] selftests/bpf: Rename test_sk_lookup_kern.c to test_ref_track_kern.c Jakub Sitnicki
2020-07-02  9:24 ` [PATCH bpf-next v3 16/16] selftests/bpf: Tests for BPF_SK_LOOKUP attach point Jakub Sitnicki
2020-07-02 11:01   ` Lorenz Bauer
2020-07-02 12:59     ` Jakub Sitnicki
2020-07-09  4:28       ` Andrii Nakryiko
2020-07-09 15:54         ` Jakub Sitnicki
2020-07-02 11:05 ` [PATCH bpf-next v3 00/16] Run a BPF program on socket lookup Lorenz Bauer

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=87k0zcam51.fsf@cloudflare.com \
    --to=jakub@cloudflare.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kernel-team@cloudflare.com \
    --cc=kuba@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.