From: Stanislav Fomichev <sdf@fomichev.me>
To: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ys114321@gmail.com,
daniel@iogearbox.net, davem@davemloft.net, ast@kernel.org
Subject: Re: [PATCH v4 bpf-next 0/4] selftests/bpf: fix compiling loop{1,2,3}.c on s390
Date: Thu, 11 Jul 2019 13:35:08 -0700 [thread overview]
Message-ID: <20190711203508.GC16709@mini-arch> (raw)
In-Reply-To: <20190711142930.68809-1-iii@linux.ibm.com>
On 07/11, Ilya Leoshkevich wrote:
> Use PT_REGS_RC(ctx) instead of ctx->rax, which is not present on s390.
>
> This patch series consists of three preparatory commits, which make it
> possible to use PT_REGS_RC in BPF selftests, followed by the actual fix.
>
> > > Will this also work for 32-bit x86?
> > Thanks, this is a good catch: this builds, but makes 64-bit accesses, as
> > if it used the 64-bit variant of pt_regs. I will fix this.
> I found four problems in this area:
>
> 1. Selftest tracing progs are built with -target bpf, leading to struct
> pt_regs and friends being interpreted incorrectly.
> 2. When the Makefile is adjusted to build them without -target bpf, it
> still lacks -m32/-m64, leading to a similar issue.
> 3. There is no __i386__ define, leading to incorrect userspace struct
> pt_regs variant being chosen for x86.
> 4. Finally, there is an issue in my patch: when 1-3 are fixed, it fails
> to build, since i386 defines yet another set of field names.
>
> I will send fixes for problems 1-3 separately, I believe for this patch
> series to be correct, it's enough to fix #4 (which I did by adding
> another #ifdef).
>
> I've also changed ARCH to SRCARCH in patch #1, since while ARCH can be
> e.g. "i386", SRCARCH always corresponds to directory names under arch/.
>
> v1->v2: Split into multiple patches.
> v2->v3: Added arm64 support.
> v3->v4: Added i386 support, use SRCARCH instead of ARCH.
Still looks good to me, thanks!
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Again, should probably go via bpf to fix the existing tests, not bpf-next
(but I see bpf tree is not synced with net tree yet).
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>
>
next prev parent reply other threads:[~2019-07-11 20:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 14:29 [PATCH v4 bpf-next 0/4] selftests/bpf: fix compiling loop{1,2,3}.c on s390 Ilya Leoshkevich
2019-07-11 14:29 ` [PATCH v4 bpf-next 1/4] selftests/bpf: compile progs with -D__TARGET_ARCH_$(SRCARCH) Ilya Leoshkevich
2019-07-12 0:53 ` Andrii Nakryiko
2019-07-12 8:59 ` Ilya Leoshkevich
2019-07-12 17:28 ` Andrii Nakryiko
2019-07-11 14:29 ` [PATCH v4 bpf-next 2/4] selftests/bpf: fix s930 -> s390 typo Ilya Leoshkevich
2019-07-12 0:50 ` Andrii Nakryiko
2019-07-11 14:29 ` [PATCH v4 bpf-next 3/4] selftests/bpf: make PT_REGS_* work in userspace Ilya Leoshkevich
2019-07-12 0:49 ` Andrii Nakryiko
2019-07-11 14:29 ` [PATCH v4 bpf-next 4/4] selftests/bpf: fix compiling loop{1,2,3}.c on s390 Ilya Leoshkevich
2019-07-11 20:35 ` Stanislav Fomichev [this message]
2019-07-12 8:55 ` [PATCH v4 bpf-next 0/4] " Ilya Leoshkevich
2019-07-12 13:44 ` Daniel Borkmann
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=20190711203508.GC16709@mini-arch \
--to=sdf@fomichev.me \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=iii@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=ys114321@gmail.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 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.