netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Yonghong Song <yhs@fb.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Martin KaFai Lau <kafai@fb.com>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next v2 13/20] bpf: add bpf_seq_printf and bpf_seq_write helpers
Date: Wed, 6 May 2020 10:37:05 -0700	[thread overview]
Message-ID: <CAEf4Bzb-COkgcLB=HK4ahtnEFD7QGY0s=Qb-kWTBKK56319JAg@mail.gmail.com> (raw)
In-Reply-To: <20200504062602.2048597-1-yhs@fb.com>

On Sun, May 3, 2020 at 11:26 PM Yonghong Song <yhs@fb.com> wrote:
>
> Two helpers bpf_seq_printf and bpf_seq_write, are added for
> writing data to the seq_file buffer.
>
> bpf_seq_printf supports common format string flag/width/type
> fields so at least I can get identical results for
> netlink and ipv6_route targets.
>

Does seq_printf() has its own format string specification? Is there
any documentation explaining? I was confused by few different checks
below...

> For bpf_seq_printf and bpf_seq_write, return value -EOVERFLOW
> specifically indicates a write failure due to overflow, which
> means the object will be repeated in the next bpf invocation
> if object collection stays the same. Note that if the object
> collection is changed, depending how collection traversal is
> done, even if the object still in the collection, it may not
> be visited.
>
> bpf_seq_printf may return -EBUSY meaning that internal percpu
> buffer for memory copy of strings or other pointees is
> not available. Bpf program can return 1 to indicate it
> wants the same object to be repeated. Right now, this should not
> happen on no-RT kernels since migrate_enable(), which guards
> bpf prog call, calls preempt_enable().

You probably meant migrate_disable()/preempt_disable(), right? But
could it still happen, at least due to NMI? E.g., perf_event BPF
program gets triggered during bpf_iter program execution? I think for
perf_event_output function, we have 3 levels, for one of each possible
"contexts"? Should we do something like that here as well?

>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
>  include/uapi/linux/bpf.h       |  32 +++++-
>  kernel/trace/bpf_trace.c       | 195 +++++++++++++++++++++++++++++++++
>  scripts/bpf_helpers_doc.py     |   2 +
>  tools/include/uapi/linux/bpf.h |  32 +++++-
>  4 files changed, 259 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 97ceb0f2e539..e440a9d5cca2 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -3076,6 +3076,34 @@ union bpf_attr {
>   *             See: clock_gettime(CLOCK_BOOTTIME)
>   *     Return
>   *             Current *ktime*.
> + *

[...]

> +BPF_CALL_5(bpf_seq_printf, struct seq_file *, m, char *, fmt, u32, fmt_size,
> +          const void *, data, u32, data_len)
> +{
> +       int err = -EINVAL, fmt_cnt = 0, memcpy_cnt = 0;
> +       int i, buf_used, copy_size, num_args;
> +       u64 params[MAX_SEQ_PRINTF_VARARGS];
> +       struct bpf_seq_printf_buf *bufs;
> +       const u64 *args = data;
> +
> +       buf_used = this_cpu_inc_return(bpf_seq_printf_buf_used);
> +       if (WARN_ON_ONCE(buf_used > 1)) {
> +               err = -EBUSY;
> +               goto out;
> +       }
> +
> +       bufs = this_cpu_ptr(&bpf_seq_printf_buf);
> +
> +       /*
> +        * bpf_check()->check_func_arg()->check_stack_boundary()
> +        * guarantees that fmt points to bpf program stack,
> +        * fmt_size bytes of it were initialized and fmt_size > 0
> +        */
> +       if (fmt[--fmt_size] != 0)

If we allow fmt_size == 0, this will need to be changed.

> +               goto out;
> +
> +       if (data_len & 7)
> +               goto out;
> +
> +       for (i = 0; i < fmt_size; i++) {
> +               if (fmt[i] == '%' && (!data || !data_len))

So %% escaping is not supported?

> +                       goto out;
> +       }
> +
> +       num_args = data_len / 8;
> +
> +       /* check format string for allowed specifiers */
> +       for (i = 0; i < fmt_size; i++) {
> +               if ((!isprint(fmt[i]) && !isspace(fmt[i])) || !isascii(fmt[i]))

why these restrictions? are they essential?

> +                       goto out;
> +
> +               if (fmt[i] != '%')
> +                       continue;
> +
> +               if (fmt_cnt >= MAX_SEQ_PRINTF_VARARGS) {
> +                       err = -E2BIG;
> +                       goto out;
> +               }
> +
> +               if (fmt_cnt >= num_args)
> +                       goto out;
> +
> +               /* fmt[i] != 0 && fmt[last] == 0, so we can access fmt[i + 1] */
> +               i++;
> +
> +               /* skip optional "[0+-][num]" width formating field */
> +               while (fmt[i] == '0' || fmt[i] == '+'  || fmt[i] == '-')

There could be space as well, as an alternative to 0.

> +                       i++;
> +               if (fmt[i] >= '1' && fmt[i] <= '9') {
> +                       i++;
> +                       while (fmt[i] >= '0' && fmt[i] <= '9')
> +                               i++;
> +               }
> +
> +               if (fmt[i] == 's') {
> +                       /* disallow any further format extensions */
> +                       if (fmt[i + 1] != 0 &&
> +                           !isspace(fmt[i + 1]) &&
> +                           !ispunct(fmt[i + 1]))
> +                               goto out;

I'm not sure I follow this check either. printf("%sbla", "whatever")
is a perfectly fine format string. Unless seq_printf has some
additional restrictions?

> +
> +                       /* try our best to copy */
> +                       if (memcpy_cnt >= MAX_SEQ_PRINTF_MAX_MEMCPY) {
> +                               err = -E2BIG;
> +                               goto out;
> +                       }
> +

[...]

> +
> +static int bpf_seq_printf_btf_ids[5];
> +static const struct bpf_func_proto bpf_seq_printf_proto = {
> +       .func           = bpf_seq_printf,
> +       .gpl_only       = true,
> +       .ret_type       = RET_INTEGER,
> +       .arg1_type      = ARG_PTR_TO_BTF_ID,
> +       .arg2_type      = ARG_PTR_TO_MEM,
> +       .arg3_type      = ARG_CONST_SIZE,

It feels like allowing zero shouldn't hurt too much?

> +       .arg4_type      = ARG_PTR_TO_MEM_OR_NULL,
> +       .arg5_type      = ARG_CONST_SIZE_OR_ZERO,
> +       .btf_id         = bpf_seq_printf_btf_ids,
> +};
> +
> +BPF_CALL_3(bpf_seq_write, struct seq_file *, m, const void *, data, u32, len)
> +{
> +       return seq_write(m, data, len) ? -EOVERFLOW : 0;
> +}
> +
> +static int bpf_seq_write_btf_ids[5];
> +static const struct bpf_func_proto bpf_seq_write_proto = {
> +       .func           = bpf_seq_write,
> +       .gpl_only       = true,
> +       .ret_type       = RET_INTEGER,
> +       .arg1_type      = ARG_PTR_TO_BTF_ID,
> +       .arg2_type      = ARG_PTR_TO_MEM,
> +       .arg3_type      = ARG_CONST_SIZE,

Same, ARG_CONST_SIZE_OR_ZERO?

> +       .btf_id         = bpf_seq_write_btf_ids,
> +};
> +

[...]

  reply	other threads:[~2020-05-06 17:37 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-04  6:25 [PATCH bpf-next v2 00/20] bpf: implement bpf iterator for kernel data Yonghong Song
2020-05-04  6:25 ` [PATCH bpf-next v2 01/20] bpf: implement an interface to register bpf_iter targets Yonghong Song
2020-05-05 21:19   ` Andrii Nakryiko
2020-05-04  6:25 ` [PATCH bpf-next v2 02/20] bpf: allow loading of a bpf_iter program Yonghong Song
2020-05-05 21:29   ` Andrii Nakryiko
2020-05-06  0:07     ` Yonghong Song
2020-05-04  6:25 ` [PATCH bpf-next v2 03/20] bpf: support bpf tracing/iter programs for BPF_LINK_CREATE Yonghong Song
2020-05-05 21:30   ` Andrii Nakryiko
2020-05-06  0:14     ` Yonghong Song
2020-05-06  0:54       ` Alexei Starovoitov
2020-05-06  3:09         ` Andrii Nakryiko
2020-05-06 18:08           ` Alexei Starovoitov
2020-05-04  6:25 ` [PATCH bpf-next v2 04/20] bpf: support bpf tracing/iter programs for BPF_LINK_UPDATE Yonghong Song
2020-05-05 21:32   ` Andrii Nakryiko
2020-05-04  6:25 ` [PATCH bpf-next v2 05/20] bpf: implement bpf_seq_read() for bpf iterator Yonghong Song
2020-05-05 19:56   ` Andrii Nakryiko
2020-05-05 19:57     ` Alexei Starovoitov
2020-05-05 20:25     ` Yonghong Song
2020-05-05 21:08       ` Andrii Nakryiko
2020-05-04  6:25 ` [PATCH bpf-next v2 06/20] bpf: create anonymous " Yonghong Song
2020-05-05 20:11   ` Andrii Nakryiko
2020-05-05 20:28     ` Yonghong Song
2020-05-04  6:25 ` [PATCH bpf-next v2 07/20] bpf: create file " Yonghong Song
2020-05-05 20:15   ` Andrii Nakryiko
2020-05-04  6:25 ` [PATCH bpf-next v2 08/20] bpf: implement common macros/helpers for target iterators Yonghong Song
2020-05-05 20:25   ` Andrii Nakryiko
2020-05-05 20:30     ` Yonghong Song
2020-05-05 21:10       ` Andrii Nakryiko
2020-05-04  6:25 ` [PATCH bpf-next v2 09/20] bpf: add bpf_map iterator Yonghong Song
2020-05-06  5:11   ` Andrii Nakryiko
2020-05-04  6:25 ` [PATCH bpf-next v2 10/20] net: bpf: add netlink and ipv6_route bpf_iter targets Yonghong Song
2020-05-06  5:21   ` Andrii Nakryiko
2020-05-06 17:32     ` Yonghong Song
2020-05-04  6:25 ` [PATCH bpf-next v2 11/20] bpf: add task and task/file iterator targets Yonghong Song
2020-05-06  7:30   ` Andrii Nakryiko
2020-05-06 18:24     ` Yonghong Song
2020-05-06 20:51       ` Andrii Nakryiko
2020-05-06 21:20         ` Yonghong Song
2020-05-04  6:26 ` [PATCH bpf-next v2 12/20] bpf: add PTR_TO_BTF_ID_OR_NULL support Yonghong Song
2020-05-05 20:27   ` Andrii Nakryiko
2020-05-04  6:26 ` [PATCH bpf-next v2 13/20] bpf: add bpf_seq_printf and bpf_seq_write helpers Yonghong Song
2020-05-06 17:37   ` Andrii Nakryiko [this message]
2020-05-06 21:42     ` Yonghong Song
2020-05-08 18:15       ` Andrii Nakryiko
2020-05-04  6:26 ` [PATCH bpf-next v2 14/20] bpf: handle spilled PTR_TO_BTF_ID properly when checking stack_boundary Yonghong Song
2020-05-06 17:38   ` Andrii Nakryiko
2020-05-06 21:47     ` Yonghong Song
2020-05-04  6:26 ` [PATCH bpf-next v2 15/20] bpf: support variable length array in tracing programs Yonghong Song
2020-05-06 17:40   ` Andrii Nakryiko
2020-05-04  6:26 ` [PATCH bpf-next v2 16/20] tools/libbpf: add bpf_iter support Yonghong Song
2020-05-06  5:44   ` Andrii Nakryiko
2020-05-04  6:26 ` [PATCH bpf-next v2 17/20] tools/bpftool: add bpf_iter support for bptool Yonghong Song
2020-05-04  6:26 ` [PATCH bpf-next v2 18/20] tools/bpf: selftests: add iterator programs for ipv6_route and netlink Yonghong Song
2020-05-06  6:01   ` Andrii Nakryiko
2020-05-07  1:09     ` Yonghong Song
2020-05-08 18:17       ` Andrii Nakryiko
2020-05-06  6:04   ` Andrii Nakryiko
2020-05-06 23:07     ` Yonghong Song
2020-05-04  6:26 ` [PATCH bpf-next v2 19/20] tools/bpf: selftests: add iter progs for bpf_map/task/task_file Yonghong Song
2020-05-06  6:14   ` Andrii Nakryiko
2020-05-04  6:26 ` [PATCH bpf-next v2 20/20] tools/bpf: selftests: add bpf_iter selftests Yonghong Song
2020-05-06  6:39   ` 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='CAEf4Bzb-COkgcLB=HK4ahtnEFD7QGY0s=Qb-kWTBKK56319JAg@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --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).