All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: KP Singh <kpsingh@chromium.org>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	open list <linux-kernel@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Paul Turner <pjt@google.com>,
	Florent Revest <revest@chromium.org>,
	Brendan Jackman <jackmanb@chromium.org>
Subject: Re: [PATCH bpf-next 2/7] bpf: JIT helpers for fmod_ret progs
Date: Tue, 3 Mar 2020 15:56:05 -0800	[thread overview]
Message-ID: <20200303235604.mdlamwx4z2ws3fzy@ast-mbp> (raw)
In-Reply-To: <20200303222812.GA5265@chromium.org>

On Tue, Mar 03, 2020 at 11:28:12PM +0100, KP Singh wrote:
> > > +static void align16_branch_target(u8 **pprog)
> > > +{
> > > +       u8 *target, *prog = *pprog;
> > > +
> > > +       target = PTR_ALIGN(prog, 16);
> > > +       if (target != prog)
> > > +               emit_nops(&prog, target - prog);
> > > +       if (target != prog)
> > > +               pr_err("calcultion error\n");
> > 
> > this wasn't in the original code, do you feel like it's more important
> > to check this and print error?
> > 
> > also typo: calculation error, but then it's a bit brief and
> > uninformative message. So I don't know, maybe just drop it?
> 
> Ah, good catch! this is deinitely not intended to be here.
> It's a debug artifact and needs to dropped indeed.

That spurious pr_err() caught my attention as well.
After further analysis there is a bug here.
The function is missing last line:
        *pprog = prog;
Without it the nop insertion is actually not happenning.
Nops are being written, but next insns will overwrite them.
When I noticed it by code review I applied the patches to my tree
and run the tests and, as expected, all tests passed.
The existing test_xdp_veth.sh emits the most amount of unaligned
branches. Since then I've been thinking whether we could add a test
to catch things like this and couldn't come up with a way to test it
without burning a lot of code on it. So let's fix it and move on.
Could you rename this helper? May be emit_align() and pass 16 into it?
The code is not branch target specific. It's aligning the start
of the next instruction.
Also could you add a comment to:
        align16_branch_target(&prog);
        for (i = 0; i < fmod_ret->nr_progs; i++)
                emit_cond_near_jump(&branches[i], prog, branches[i],
                                    X86_JNE);
        kfree(branches);
to say that the loop is updating prior location to jump to aligned
branch target ?

  reply	other threads:[~2020-03-03 23:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 14:09 [PATCH bpf-next 0/7] Introduce BPF_MODIFY_RET tracing progs KP Singh
2020-03-03 14:09 ` [PATCH bpf-next 1/7] bpf: Refactor trampoline update code KP Singh
2020-03-03 22:12   ` Andrii Nakryiko
2020-03-03 22:24     ` KP Singh
2020-03-03 23:03       ` Andrii Nakryiko
2020-03-03 23:08         ` KP Singh
2020-03-03 14:09 ` [PATCH bpf-next 2/7] bpf: JIT helpers for fmod_ret progs KP Singh
2020-03-03 22:26   ` Andrii Nakryiko
2020-03-03 22:28     ` KP Singh
2020-03-03 23:56       ` Alexei Starovoitov [this message]
2020-03-04  1:26         ` KP Singh
2020-03-03 14:09 ` [PATCH bpf-next 3/7] bpf: Introduce BPF_MODIFY_RETURN KP Singh
2020-03-03 22:37   ` Andrii Nakryiko
2020-03-03 22:51     ` KP Singh
2020-03-03 14:09 ` [PATCH bpf-next 4/7] bpf: Attachment verification for BPF_MODIFY_RETURN KP Singh
2020-03-03 22:44   ` Andrii Nakryiko
2020-03-03 23:21     ` KP Singh
2020-03-04  0:03       ` Alexei Starovoitov
2020-03-04  1:06         ` KP Singh
2020-03-03 14:09 ` [PATCH bpf-next 5/7] tools/libbpf: Add support " KP Singh
2020-03-03 22:45   ` Andrii Nakryiko
2020-03-03 14:09 ` [PATCH bpf-next 6/7] bpf: Add test ops for BPF_PROG_TYPE_TRACING KP Singh
2020-03-03 22:51   ` Andrii Nakryiko
2020-03-03 22:57     ` KP Singh
2020-03-03 14:09 ` [PATCH bpf-next 7/7] bpf: Add selftests for BPF_MODIFY_RETURN KP Singh
2020-03-03 22:58   ` Andrii Nakryiko
2020-03-03 22:12 ` [PATCH bpf-next 0/7] Introduce BPF_MODIFY_RET tracing progs Andrii Nakryiko
2020-03-03 22:25   ` KP Singh

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=20200303235604.mdlamwx4z2ws3fzy@ast-mbp \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jackmanb@chromium.org \
    --cc=kpsingh@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pjt@google.com \
    --cc=revest@chromium.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.