All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florent Revest <revest@chromium.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alan Maguire <alan.maguire@oracle.com>,
	Steven Rostedt <rostedt@goodmis.org>, bpf <bpf@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>
Subject: Re: [PATCH] bpf: remove pointless code from bpf_do_trace_printk()
Date: Thu, 22 Apr 2021 17:46:53 +0200	[thread overview]
Message-ID: <CABRcYmKM2B1czd_ekmP3H5JapHHznV95HL4-LYOuXccKw=ZB9g@mail.gmail.com> (raw)
In-Reply-To: <CAADnVQ+wFcjMzs2G1VAKW5WnFtcBgKMeJcK3ouKJYCR7GdvfWw@mail.gmail.com>

On Thu, Apr 22, 2021 at 5:44 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Apr 22, 2021 at 8:35 AM Florent Revest <revest@chromium.org> wrote:
> > >
> > > I was having a stroll through lib/vsprintf.c and noticed bstr_printf:
> > >
> > >  * This function like C99 vsnprintf, but the difference is that vsnprintf gets
> > >  * arguments from stack, and bstr_printf gets arguments from @bin_buf which is
> > >  * a binary buffer that generated by vbin_printf.
> > >
> > > Maybe it would be easier to just build our argument buffer similarly
> > > to what vbin_printf does.
> >
> > I've been experimenting with this idea and it is quite promising :) it
> > also makes the code much cleaner, I find. I'll send a series asap.
>
> You mean to use bstr_printf internally ? That could work indeed.
> Make sure CONFIG_BINARY_PRINTF is selected.
> CONFIG_TRACING does it already.

Yes :)

> > BPF maintainers: should we fix forward or do you prefer reverting the
> > snprintf series and then re-applying another snprintf series without
> > the regression in bpf_trace_printk that mangles some argument types ?
> > (bpf_seq_printf has always been like that so no regression there)
>
> Pls send it as a follow up.
> Along with another patch to clean verifier bits we discussed.
> The merge window is approaching, so it has to be done asap.

On it ;)

  reply	other threads:[~2021-04-22 15:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 19:07 [PATCH] bpf: remove pointless code from bpf_do_trace_printk() Rasmus Villemoes
2021-04-22  3:32 ` Andrii Nakryiko
2021-04-22  7:13   ` Rasmus Villemoes
2021-04-22  9:23     ` Florent Revest
2021-04-22 10:09       ` Rasmus Villemoes
2021-04-22 12:36         ` Florent Revest
2021-04-22 15:34           ` Florent Revest
2021-04-22 15:43             ` Alexei Starovoitov
2021-04-22 15:46               ` Florent Revest [this message]
2021-04-22 18:38       ` 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='CABRcYmKM2B1czd_ekmP3H5JapHHznV95HL4-LYOuXccKw=ZB9g@mail.gmail.com' \
    --to=revest@chromium.org \
    --cc=alan.maguire@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=rostedt@goodmis.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.