On Mon, Feb 7, 2022 at 1:46 AM Heiko Carstens <hca@xxxxxxxxxxxxx> wrote: > > 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". It's just surprising and constraining that UAPI struct can be extended by adding new fields at the end :( I'll let you guys decide it for s390 and arm64. From libbpf's side, we have somewhat hacky ways to work around that, it seems.
