From: Heiko Carstens <hca@linux.ibm.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Ilya Leoshkevich <iii@linux.ibm.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 0/2] Fix bpf_perf_event_data ABI breakage
Date: Mon, 7 Feb 2022 10:46:08 +0100 [thread overview]
Message-ID: <YgDqYFsLwkWZvX0+@osiris> (raw)
In-Reply-To: <CAEf4BzZfn4-dbnRcsStu+EoKD12EoKCShcoAVH9Gj0mqieBAaw@mail.gmail.com>
On Sun, Feb 06, 2022 at 10:23:19PM -0800, Andrii Nakryiko wrote:
> I'm not sure the origins of the need for user_pt_regs (as opposed to
> using pt_regs directly, like x86-64 does), but with CO-RE and
> vmlinux.h it would be more reliable and straightforward to just stick
> to kernel-internal struct pt_regs everywhere. And for non-CO-RE macros
> maybe just using an offset within struct pt_regs (i.e.,
> offsetofend(gprs)) would do it?
user_pt_regs was introduced on s390 because struct pt_regs is _not_
stable. Only the first n entries (aka user_pt_regs) are supposed to be
stable.
We could of course reduce struct pt_regs to the bare minimum, which seems
to be the current user_pt_regs plus orig_gpr2; which semantically would
match more or less what x86 has.
Then move pt_regs to uapi, so it is clear that it cannot be changed
anymore, and have additional data in a separate structure on the stack,
which has pt_regs at the beginning, and access this additional data with
container_of & friends.
I guess that could work, even though this requires to keep user_pt_regs
"for historical reasons".
next prev parent reply other threads:[~2022-02-07 10:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-06 14:53 [PATCH bpf-next 0/2] Fix bpf_perf_event_data ABI breakage Ilya Leoshkevich
2022-02-06 14:53 ` [PATCH bpf-next 1/2] s390/bpf: Introduce user_pt_regs_v2 Ilya Leoshkevich
2022-02-06 14:53 ` [PATCH bpf-next 2/2] arm64/bpf: Introduce struct user_pt_regs_v2 Ilya Leoshkevich
2022-02-06 19:31 ` [PATCH bpf-next 0/2] Fix bpf_perf_event_data ABI breakage Andrii Nakryiko
2022-02-06 19:57 ` Ilya Leoshkevich
2022-02-07 6:23 ` Andrii Nakryiko
2022-02-07 9:46 ` Heiko Carstens [this message]
2022-02-07 20:09 ` Andrii Nakryiko
2022-02-07 11:52 ` Ilya Leoshkevich
2022-02-07 20:08 ` 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=YgDqYFsLwkWZvX0+@osiris \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=borntraeger@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=daniel@iogearbox.net \
--cc=gor@linux.ibm.com \
--cc=iii@linux.ibm.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.