bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Lorenz Bauer <lmb@cloudflare.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Theo Julienne <theojulienne@github.com>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	clang-built-linux@googlegroups.com
Subject: Re: [PATCH 1/1] selftests/bpf: add cls_redirect classifier
Date: Sat, 2 May 2020 01:48:51 +0200	[thread overview]
Message-ID: <185417b8-0d50-f8a3-7a09-949066579732@iogearbox.net> (raw)
In-Reply-To: <CACAyw98nK_Vkstp-vEqNwKXtoCRnTOPr7Eh+ziH56tJGbnPsig@mail.gmail.com>

On 4/27/20 11:45 AM, Lorenz Bauer wrote:
> On Sun, 26 Apr 2020 at 18:33, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
[...]
>>> +/* Linux packet pointers are either aligned to NET_IP_ALIGN (aka 2 bytes),
>>> + * or not aligned if the arch supports efficient unaligned access.
>>> + *
>>> + * Since the verifier ensures that eBPF packet accesses follow these rules,
>>> + * we can tell LLVM to emit code as if we always had a larger alignment.
>>> + * It will yell at us if we end up on a platform where this is not valid.
>>> + */
>>> +typedef uint8_t *net_ptr __attribute__((align_value(8)));
>>
>> Wow. I didn't know about this attribute.
>> I wonder whether it can help Daniel's memcpy hack.
> 
> Yes, I think so.

Just for some more context [0]. I think the problem is a bit more complex in
general. Generally, _any_ kind of pointer to some data (except for the stack)
is currently treated as byte-by-byte copy from __builtin_memcpy() and other
similarly available __builtin_*() helpers on BPF backend since the backend
cannot make any assumptions about the data's alignment and whether unaligned
access from the underlying arch is ok & efficient (the latter the verifier
does judge for us however). So it's definitely not just limited to xdp->data.
There is also the issue that while access to any non-stack data can be
unaligned, access to the stack however cannot. I've discussed a while back
with Yonghong about potential solutions. One would be to add a small patch
to the BPF backend to enable __builtin_*() helpers to allow for unaligned
access which could then be opt-ed in e.g. via -mattr from llc for the case
when we know that the compiled program only runs on archs with efficient
unaligned access anyway. However, this still potentially breaks with the BPF
stack for the case when objects are, for example, larger than size 8 but with
a natural alignment smaller than 8 where __builtin_memcpy() would then decide
to emit dw-typed load/stores. But for these cases could then be annotated via
__aligned(8) on stack. So this is basically what we do right now as a generic
workaround in Cilium [0], meaning, our own memcpy/memset with optimal number
of instructions and __aligned(8) where needed; most of the time this __aligned(8)
is not needed, so it's really just a few places, and we also have a cocci
scripts to catch these during development if needed. Anyway, real thing would
be to allow the BPF stack for unaligned access as well and then BPF backend
could nicely solve this in a native way w/o any workarounds, but that is tbd.

Thanks,
Daniel

   [0] https://github.com/cilium/cilium/blob/master/bpf/include/bpf/builtins.h

  reply	other threads:[~2020-05-01 23:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 18:55 [PATCH 0/1] Open source our TC classifier Lorenz Bauer
2020-04-24 18:55 ` [PATCH 1/1] selftests/bpf: add cls_redirect classifier Lorenz Bauer
2020-04-26 17:33   ` Alexei Starovoitov
2020-04-27  9:45     ` Lorenz Bauer
2020-05-01 23:48       ` Daniel Borkmann [this message]
2020-05-04 23:48         ` Alexei Starovoitov
2020-05-05 13:37           ` Daniel Borkmann
2020-05-06  1:30             ` Alexei Starovoitov

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=185417b8-0d50-f8a3-7a09-949066579732@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lmb@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=theojulienne@github.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).