All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Heiko Carstens <hca@linux.ibm.com>, Ilya Leoshkevich <iii@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Björn Töpel" <bjorn@kernel.org>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	bpf@vger.kernel.org, "Catalin Marinas" <catalin.marinas@arm.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Luke Nelson" <luke.r.nels@gmail.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Will Deacon" <will@kernel.org>
Subject: Re: [PATCH bpf-next 1/3] s390/bpf: Add orig_gpr2 to user_pt_regs
Date: Fri, 04 Feb 2022 08:21:12 +0000	[thread overview]
Message-ID: <1643962017.hhlhw119x7.naveen@linux.ibm.com> (raw)
In-Reply-To: <1643952491.peuih6eln6.naveen@linux.ibm.com>

Naveen N. Rao wrote:
> Hi Heiko,
> 
> Heiko Carstens wrote:
>> On Wed, Feb 02, 2022 at 12:41:58AM +0100, Ilya Leoshkevich wrote:
>>> user_pt_regs is used by eBPF in order to access userspace registers -
>>> see commit 466698e654e8 ("s390/bpf: correct broken uapi for
>>> BPF_PROG_TYPE_PERF_EVENT program type"). In order to access the first
>>> syscall argument from eBPF programs, we need to export orig_gpr2.
>>> 
>>> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>>> ---
>>>  arch/s390/include/asm/ptrace.h      | 2 +-
>>>  arch/s390/include/uapi/asm/ptrace.h | 1 +
>>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/s390/include/asm/ptrace.h b/arch/s390/include/asm/ptrace.h
>>> index 4ffa8e7f0ed3..c8698e643904 100644
>>> --- a/arch/s390/include/asm/ptrace.h
>>> +++ b/arch/s390/include/asm/ptrace.h
>>> @@ -83,9 +83,9 @@ struct pt_regs {
>>>  			unsigned long args[1];
>>>  			psw_t psw;
>>>  			unsigned long gprs[NUM_GPRS];
>>> +			unsigned long orig_gpr2;
>>>  		};
>>>  	};
>>> -	unsigned long orig_gpr2;
>>>  	union {
>>>  		struct {
>>>  			unsigned int int_code;
>>> diff --git a/arch/s390/include/uapi/asm/ptrace.h b/arch/s390/include/uapi/asm/ptrace.h
>>> index ad64d673b5e6..b3dec603f507 100644
>>> --- a/arch/s390/include/uapi/asm/ptrace.h
>>> +++ b/arch/s390/include/uapi/asm/ptrace.h
>>> @@ -295,6 +295,7 @@ typedef struct {
>>>  	unsigned long args[1];
>>>  	psw_t psw;
>>>  	unsigned long gprs[NUM_GPRS];
>>> +	unsigned long orig_gpr2;
>>>  } user_pt_regs;
>> 
>> Isn't this broken on nearly all architectures? I just checked powerpc,
>> arm64, and riscv. While powerpc seems to mirror pt_regs as user_pt_regs,
>> and therefore exports orig_gpr3, the bpf macros still seem to access the
>> wrong location to access the first syscall parameter(?).
> 
> On powerpc, gpr[3] continues to be valid on syscall entry (so this test 
> passes on powerpc), though orig_gpr3 will remain valid throughout.

Hmm.. we can't use orig_gpr3 since we don't use a syscall wrapper. All 
system calls just receive the parameters directly.

- Naveen

  reply	other threads:[~2022-02-04  8:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01 23:41 [PATCH bpf-next 0/3] libbpf: Fix accessing the first syscall argument on s390 Ilya Leoshkevich
2022-02-01 23:41 ` [PATCH bpf-next 1/3] s390/bpf: Add orig_gpr2 to user_pt_regs Ilya Leoshkevich
2022-02-02 14:19   ` Vasily Gorbik
2022-02-02 17:23     ` Christian Borntraeger
2022-02-03  9:40       ` Heiko Carstens
2022-02-02 20:14   ` Heiko Carstens
2022-02-02 22:49     ` Andrii Nakryiko
2022-02-04  6:07     ` Naveen N. Rao
2022-02-04  8:21       ` Naveen N. Rao [this message]
2022-02-04 12:20         ` Ilya Leoshkevich
2022-02-04 13:49           ` Naveen N. Rao
2022-02-01 23:41 ` [PATCH bpf-next 2/3] selftests/bpf: Fix an endianness issue in bpf_syscall_macro test Ilya Leoshkevich
2022-02-01 23:42 ` [PATCH bpf-next 3/3] libbpf: Fix accessing the first syscall argument on s390 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=1643962017.hhlhw119x7.naveen@linux.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bjorn@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=iii@linux.ibm.com \
    --cc=luke.r.nels@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=will@kernel.org \
    /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.