bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Dave Marchevsky <davemarchevsky@fb.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>, Yonghong Song <yhs@fb.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH v3 bpf-next 4/7] libbpf: use static const fmt string in __bpf_printk
Date: Sun, 29 Aug 2021 09:57:14 -0700	[thread overview]
Message-ID: <20210829165714.wghn236g2ka7lgna@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <3da3377c-7f79-9e07-7deb-4fca6abae8fd@fb.com>

On Sat, Aug 28, 2021 at 12:40:17PM -0400, Dave Marchevsky wrote:
> On 8/28/21 1:20 AM, Dave Marchevsky wrote:   
> > The __bpf_printk convenience macro was using a 'char' fmt string holder
> > as it predates support for globals in libbpf. Move to more efficient
> > 'static const char', but provide a fallback to the old way via
> > BPF_NO_GLOBAL_DATA so users on old kernels can still use the macro.
> > 
> > Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> > ---
> >  tools/lib/bpf/bpf_helpers.h | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h
> > index 5f087306cdfe..a1d5ec6f285c 100644
> > --- a/tools/lib/bpf/bpf_helpers.h
> > +++ b/tools/lib/bpf/bpf_helpers.h
> > @@ -216,10 +216,16 @@ enum libbpf_tristate {
> >  		     ___param, sizeof(___param));		\
> >  })
> >  
> > +#ifdef BPF_NO_GLOBAL_DATA
> > +#define BPF_PRINTK_FMT_TYPE char
> > +#else
> > +#define BPF_PRINTK_FMT_TYPE static const char
> 
> The reference_tracking prog test is failing as a result of this.
> Specifically, it fails to load bpf_sk_lookup_test0 prog, which 
> has a bpf_printk:
> 
>   47: (b4) w3 = 0
>   48: (18) r1 = 0x0
>   50: (b4) w2 = 7
>   51: (85) call bpf_trace_printk#6
>   R1 type=inv expected=fp, pkt, pkt_meta, map_key, map_value, mem, rdonly_buf, rdwr_buf
> 
> Setting BPF_NO_GLOBAL_DATA in the test results in a pass

hmm. that's odd. pls investigate.
Worst case we can just drop this patch for now.
The failing printk is this one, right?
bpf_printk("sk=%d\n", sk ? 1 : 0);
iirc we had an issue related to ?: operand being used as an argument
and llvm generating interesting code path with 'sk' and the later
if (sk) bpf_sk_release(sk);
would not be properly recognized by the verifier leading it to
believe that sk may not be released in some cases.
That printk was triggering such interesting llvm codegen.
See commit d844a71bff0f ("bpf: Selftests, add printk to test_sk_lookup_kern to encode null ptr check")

  reply	other threads:[~2021-08-29 16:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-28  5:19 [PATCH v3 bpf-next 0/7] bpf: implement variadic printk helper Dave Marchevsky
2021-08-28  5:20 ` [PATCH v3 bpf-next 1/7] bpf: merge printk and seq_printf VARARG max macros Dave Marchevsky
2021-08-28  5:20 ` [PATCH v3 bpf-next 2/7] bpf: add bpf_trace_vprintk helper Dave Marchevsky
2021-08-30 23:35   ` Andrii Nakryiko
2021-09-03  8:00   ` Daniel Borkmann
2021-09-13 17:30     ` Dave Marchevsky
2021-08-28  5:20 ` [PATCH v3 bpf-next 3/7] libbpf: Modify bpf_printk to choose helper based on arg count Dave Marchevsky
2021-08-28 16:44   ` Dave Marchevsky
2021-08-28  5:20 ` [PATCH v3 bpf-next 4/7] libbpf: use static const fmt string in __bpf_printk Dave Marchevsky
2021-08-28 16:40   ` Dave Marchevsky
2021-08-29 16:57     ` Alexei Starovoitov [this message]
2021-08-31  0:36       ` Andrii Nakryiko
2021-08-31  0:37   ` Andrii Nakryiko
2021-08-28  5:20 ` [PATCH v3 bpf-next 5/7] bpftool: only probe trace_vprintk feature in 'full' mode Dave Marchevsky
2021-08-28  5:20 ` [PATCH v3 bpf-next 6/7] selftests/bpf: Migrate prog_tests/trace_printk CHECKs to ASSERTs Dave Marchevsky
2021-08-31  0:03   ` Andrii Nakryiko
2021-08-28  5:20 ` [PATCH v3 bpf-next 7/7] selftests/bpf: add trace_vprintk test prog Dave Marchevsky
2021-08-31  0:04   ` 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=20210829165714.wghn236g2ka7lgna@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davemarchevsky@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).