All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	"Naveen N . Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Mark Rutland <mark.rutland@arm.com>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v4 06/14] libbpf: Add PT_REGS_SYSCALL_REGS macro
Date: Wed, 09 Feb 2022 00:26:33 +0100	[thread overview]
Message-ID: <aac0bbcaa484df34484eb928af208743167d50dc.camel@linux.ibm.com> (raw)
In-Reply-To: <CAEf4BzagHVnAEz+22eFU=EeFuwvBGyGUbfT8XCmv4zF97KdUBA@mail.gmail.com>

On Tue, 2022-02-08 at 14:08 -0800, Andrii Nakryiko wrote:
> On Mon, Feb 7, 2022 at 9:16 PM Ilya Leoshkevich <iii@linux.ibm.com>
> wrote:
> > 
> > Depending on whether or not an arch has ARCH_HAS_SYSCALL_WRAPPER,
> > syscall arguments must be accessed through a different set of
> > registers. Provide PT_REGS_SYSCALL_REGS macro to abstract away
> > that difference.
> > 
> > Reported-by: Heiko Carstens <hca@linux.ibm.com>
> > Co-developed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> > Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> 
> Again, there was nothing wrong with the way you did it in v3, please
> revert to that one.

I've realized that, even though fully correct, v3 looked somewhat
ad-hoc: it defined PT_REGS_SYSCALL_REGS for different architectures
without explaining why this particular arch has this parciular way to
access syscall arguments.

So I've decided to switch to the existing terminology, as Naveen
proposed [1]:

- arches that select ARCH_HAS_SYSCALL_WRAPPER in Kconfig get a
  __BPF_ARCH_HAS_SYSCALL_WRAPPER in bpf_tracing.h

- syscall handler calling convention is (at least partially) determined
  by whether or not an arch has a sycall wrapper as described in
  ARCH_HAS_SYSCALL_WRAPPER help text

I can, of course, switch back to v3 - both patches look functionally
identical - but this one seems to be a bit easier to understand.

[1]
https://lore.kernel.org/bpf/1643991537.bfyv1b2oym.naveen@linux.ibm.com/#t

> 
> >  tools/lib/bpf/bpf_tracing.h | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/tools/lib/bpf/bpf_tracing.h
> > b/tools/lib/bpf/bpf_tracing.h
> > index 82f1e935d549..7a015ee8fb11 100644
> > --- a/tools/lib/bpf/bpf_tracing.h
> > +++ b/tools/lib/bpf/bpf_tracing.h
> > @@ -64,6 +64,8 @@
> > 
> >  #if defined(bpf_target_x86)
> > 
> > +#define __BPF_ARCH_HAS_SYSCALL_WRAPPER
> > +
> >  #if defined(__KERNEL__) || defined(__VMLINUX_H__)
> > 
> >  #define __PT_PARM1_REG di
> > @@ -114,6 +116,8 @@
> > 
> >  #elif defined(bpf_target_s390)
> > 
> > +#define __BPF_ARCH_HAS_SYSCALL_WRAPPER
> > +
> >  /* s390 provides user_pt_regs instead of struct pt_regs to
> > userspace */
> >  #define __PT_REGS_CAST(x) ((const user_pt_regs *)(x))
> >  #define __PT_PARM1_REG gprs[2]
> > @@ -142,6 +146,8 @@
> > 
> >  #elif defined(bpf_target_arm64)
> > 
> > +#define __BPF_ARCH_HAS_SYSCALL_WRAPPER
> > +
> >  /* arm64 provides struct user_pt_regs instead of struct pt_regs to
> > userspace */
> >  #define __PT_REGS_CAST(x) ((const struct user_pt_regs *)(x))
> >  #define __PT_PARM1_REG regs[0]
> > @@ -344,6 +350,17 @@ struct pt_regs;
> > 
> >  #endif /* defined(bpf_target_defined) */
> > 
> > +/*
> > + * When invoked from a syscall handler BPF_KPROBE, returns a
> > pointer to a
> > + * struct pt_regs containing syscall arguments, that is suitable
> > for passing to
> > + * PT_REGS_PARMn_SYSCALL() and PT_REGS_PARMn_CORE_SYSCALL().
> > + */
> > +#ifdef __BPF_ARCH_HAS_SYSCALL_WRAPPER
> > +#define PT_REGS_SYSCALL_REGS(ctx) ((struct pt_regs
> > *)PT_REGS_PARM1(ctx))
> > +#else
> > +#define PT_REGS_SYSCALL_REGS(ctx) ctx
> > +#endif
> > +
> >  #ifndef ___bpf_concat
> >  #define ___bpf_concat(a, b) a ## b
> >  #endif
> > --
> > 2.34.1
> > 


  reply	other threads:[~2022-02-08 23:27 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08  5:16 [PATCH bpf-next v4 00/14] Fix accessing syscall arguments Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 01/14] selftests/bpf: Fix an endianness issue in bpf_syscall_macro test Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 02/14] selftests/bpf: Fix a potential offsetofend redefinition in test_cls_redirect Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 03/14] selftests/bpf: Compile bpf_syscall_macro test also with user headers Ilya Leoshkevich
2022-02-08 22:06   ` Andrii Nakryiko
2022-02-08 23:11     ` Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 04/14] libbpf: Fix a typo in bpf_tracing.h Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 05/14] libbpf: Generalize overriding syscall parameter access macros Ilya Leoshkevich
2022-02-08 22:05   ` Andrii Nakryiko
2022-02-08 23:08     ` Ilya Leoshkevich
2022-02-08 23:21       ` Andrii Nakryiko
2022-02-08 23:30         ` Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 06/14] libbpf: Add PT_REGS_SYSCALL_REGS macro Ilya Leoshkevich
2022-02-08 22:08   ` Andrii Nakryiko
2022-02-08 23:26     ` Ilya Leoshkevich [this message]
2022-02-08 23:43       ` Andrii Nakryiko
2022-02-08  5:16 ` [PATCH bpf-next v4 07/14] selftests/bpf: Use PT_REGS_SYSCALL_REGS in bpf_syscall_macro Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 08/14] libbpf: Use struct pt_regs when compiling with kernel headers Ilya Leoshkevich
2022-02-08 22:12   ` Andrii Nakryiko
2022-02-08 23:35     ` Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 09/14] libbpf: Fix riscv register names Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 10/14] libbpf: Move data structure manipulation macros to bpf_common_helpers.h Ilya Leoshkevich
2022-02-08 22:14   ` Andrii Nakryiko
2022-02-08 23:37     ` Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 11/14] libbpf: Fix accessing the first syscall argument on s390 Ilya Leoshkevich
2022-02-08 13:10   ` Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 12/14] s390: add a comment that warns that orig_gpr2 should not be moved Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 13/14] libbpf: Fix accessing the first syscall argument on arm64 Ilya Leoshkevich
2022-02-08  5:16 ` [PATCH bpf-next v4 14/14] arm64: add a comment that warns that orig_x0 should not be moved Ilya Leoshkevich
2022-02-08 19:25   ` Alexei Starovoitov
2022-02-08 19:46     ` Ilya Leoshkevich
2022-02-08 21:11       ` Alexei Starovoitov
2022-02-08 21:46         ` Ilya Leoshkevich
2022-02-08 22:23           ` Andrii Nakryiko
2022-02-08 23:39             ` Ilya Leoshkevich

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=aac0bbcaa484df34484eb928af208743167d50dc.camel@linux.ibm.com \
    --to=iii@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=hca@linux.ibm.com \
    --cc=mark.rutland@arm.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=paul.walmsley@sifive.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.