All of lore.kernel.org
 help / color / mirror / Atom feed
From: Puranjay Mohan <puranjay12@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Zi Shen Lim <zlim.lnx@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>
Subject: Re: [PATCH bpf-next v2 1/1] bpf, arm64: support exceptions
Date: Mon, 6 Nov 2023 10:04:09 +0100	[thread overview]
Message-ID: <CANk7y0g8SOrSAY2jqZ22v6Duu9yhHY-d39g5gJ2vA2j2Y-v53Q@mail.gmail.com> (raw)
In-Reply-To: <ZUPVbrMSNNwPw_B-@FVFF77S0Q05N.cambridge.arm.com>

Hi Mark,

On Thu, Nov 2, 2023 at 5:59 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Sun, Sep 17, 2023 at 12:00:45AM +0000, Puranjay Mohan wrote:
> > Implement arch_bpf_stack_walk() for the ARM64 JIT. This will be used
> > by bpf_throw() to unwind till the program marked as exception boundary and
> > run the callback with the stack of the main program.
> >
> > The prologue generation code has been modified to make the callback
> > program use the stack of the program marked as exception boundary where
> > callee-saved registers are already pushed.
> >
> > As the bpf_throw function never returns, if it clobbers any callee-saved
> > registers, they would remain clobbered. So, the prologue of the
> > exception-boundary program is modified to push R23 and R24 as well,
> > which the callback will then recover in its epilogue.
> >
> > The Procedure Call Standard for the Arm 64-bit Architecture[1] states
> > that registers r19 to r28 should be saved by the callee. BPF programs on
> > ARM64 already save all callee-saved registers except r23 and r24. This
> > patch adds an instruction in prologue of the  program to save these
> > two registers and another instruction in the epilogue to recover them.
> >
> > These extra instructions are only added if bpf_throw() used. Otherwise
> > the emitted prologue/epilogue remains unchanged.
> >
> > [1] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
> >
> > Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> > ---
>
> [...]
>
> > +void arch_bpf_stack_walk(bool (*consume_fn)(void *cookie, u64 ip, u64 sp, u64 bp), void *cookie)
> > +{
> > +     struct stack_info stacks[] = {
> > +             stackinfo_get_task(current),
> > +     };
>
> Can bpf_throw() only be used by BPF programs that run in task context, or is it
> possible e.g. for those to run within an IRQ handler (or otherwise on the IRQ
> stack)?

I will get back on this with more information.

>
> > +
> > +     struct unwind_state state = {
> > +             .stacks = stacks,
> > +             .nr_stacks = ARRAY_SIZE(stacks),
> > +     };
> > +     unwind_init_common(&state, current);
> > +     state.fp = (unsigned long)__builtin_frame_address(1);
> > +     state.pc = (unsigned long)__builtin_return_address(0);
> > +
> > +     if (unwind_next_frame_record(&state))
> > +             return;
> > +     while (1) {
> > +             /* We only use the fp in the exception callback. Pass 0 for sp as it's unavailable*/
> > +             if (!consume_fn(cookie, (u64)state.pc, 0, (u64)state.fp))
> > +                     break;
> > +             if (unwind_next_frame_record(&state))
> > +                     break;
> > +     }
> > +}
>
> IIUC you're not using arch_stack_walk() because you need the FP in addition to
> the PC.

Yes,

>
> Is there any other reason you need to open-code this?

No,

>
> If not, I'd rather rework the common unwinder so that it's possible to get at
> the FP. I had patches for that a while back:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/stacktrace/metadata
>
> ... and I'm happy to rebase that and pull out the minimum necessary to make
> that possible.

It would be great if you can rebase and push the code, I can rebase
this on your work and
not open code this implementation.

>
> Mark.
>

Thanks,
Puranjay

WARNING: multiple messages have this Message-ID (diff)
From: Puranjay Mohan <puranjay12@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	 Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	 Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	 KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	 Jiri Olsa <jolsa@kernel.org>, Zi Shen Lim <zlim.lnx@gmail.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	bpf@vger.kernel.org,  linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	 Kumar Kartikeya Dwivedi <memxor@gmail.com>
Subject: Re: [PATCH bpf-next v2 1/1] bpf, arm64: support exceptions
Date: Mon, 6 Nov 2023 10:04:09 +0100	[thread overview]
Message-ID: <CANk7y0g8SOrSAY2jqZ22v6Duu9yhHY-d39g5gJ2vA2j2Y-v53Q@mail.gmail.com> (raw)
In-Reply-To: <ZUPVbrMSNNwPw_B-@FVFF77S0Q05N.cambridge.arm.com>

Hi Mark,

On Thu, Nov 2, 2023 at 5:59 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Sun, Sep 17, 2023 at 12:00:45AM +0000, Puranjay Mohan wrote:
> > Implement arch_bpf_stack_walk() for the ARM64 JIT. This will be used
> > by bpf_throw() to unwind till the program marked as exception boundary and
> > run the callback with the stack of the main program.
> >
> > The prologue generation code has been modified to make the callback
> > program use the stack of the program marked as exception boundary where
> > callee-saved registers are already pushed.
> >
> > As the bpf_throw function never returns, if it clobbers any callee-saved
> > registers, they would remain clobbered. So, the prologue of the
> > exception-boundary program is modified to push R23 and R24 as well,
> > which the callback will then recover in its epilogue.
> >
> > The Procedure Call Standard for the Arm 64-bit Architecture[1] states
> > that registers r19 to r28 should be saved by the callee. BPF programs on
> > ARM64 already save all callee-saved registers except r23 and r24. This
> > patch adds an instruction in prologue of the  program to save these
> > two registers and another instruction in the epilogue to recover them.
> >
> > These extra instructions are only added if bpf_throw() used. Otherwise
> > the emitted prologue/epilogue remains unchanged.
> >
> > [1] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
> >
> > Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> > ---
>
> [...]
>
> > +void arch_bpf_stack_walk(bool (*consume_fn)(void *cookie, u64 ip, u64 sp, u64 bp), void *cookie)
> > +{
> > +     struct stack_info stacks[] = {
> > +             stackinfo_get_task(current),
> > +     };
>
> Can bpf_throw() only be used by BPF programs that run in task context, or is it
> possible e.g. for those to run within an IRQ handler (or otherwise on the IRQ
> stack)?

I will get back on this with more information.

>
> > +
> > +     struct unwind_state state = {
> > +             .stacks = stacks,
> > +             .nr_stacks = ARRAY_SIZE(stacks),
> > +     };
> > +     unwind_init_common(&state, current);
> > +     state.fp = (unsigned long)__builtin_frame_address(1);
> > +     state.pc = (unsigned long)__builtin_return_address(0);
> > +
> > +     if (unwind_next_frame_record(&state))
> > +             return;
> > +     while (1) {
> > +             /* We only use the fp in the exception callback. Pass 0 for sp as it's unavailable*/
> > +             if (!consume_fn(cookie, (u64)state.pc, 0, (u64)state.fp))
> > +                     break;
> > +             if (unwind_next_frame_record(&state))
> > +                     break;
> > +     }
> > +}
>
> IIUC you're not using arch_stack_walk() because you need the FP in addition to
> the PC.

Yes,

>
> Is there any other reason you need to open-code this?

No,

>
> If not, I'd rather rework the common unwinder so that it's possible to get at
> the FP. I had patches for that a while back:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/stacktrace/metadata
>
> ... and I'm happy to rebase that and pull out the minimum necessary to make
> that possible.

It would be great if you can rebase and push the code, I can rebase
this on your work and
not open code this implementation.

>
> Mark.
>

Thanks,
Puranjay

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-11-06  9:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-17  0:00 [PATCH bpf-next v2 0/1] bpf, arm64: Support Exceptions Puranjay Mohan
2023-09-17  0:00 ` Puranjay Mohan
2023-09-17  0:00 ` [PATCH bpf-next v2 1/1] bpf, arm64: support exceptions Puranjay Mohan
2023-09-17  0:00   ` Puranjay Mohan
2023-09-17  1:50   ` Kumar Kartikeya Dwivedi
2023-09-17  1:50     ` Kumar Kartikeya Dwivedi
2023-09-18 14:15   ` Xu Kuohai
2023-09-18 14:15     ` Xu Kuohai
2023-09-21 13:16     ` Puranjay Mohan
2023-09-21 13:16       ` Puranjay Mohan
2023-09-21 13:53       ` Xu Kuohai
2023-09-21 13:53         ` Xu Kuohai
2023-09-21 14:28         ` Puranjay Mohan
2023-09-21 14:28           ` Puranjay Mohan
2023-11-02 16:59   ` Mark Rutland
2023-11-02 16:59     ` Mark Rutland
2023-11-06  9:04     ` Puranjay Mohan [this message]
2023-11-06  9:04       ` Puranjay Mohan
2023-11-08 10:32       ` Mark Rutland
2023-11-08 10:32         ` Mark Rutland
2023-11-13 22:53         ` Puranjay Mohan
2023-11-13 22:53           ` Puranjay Mohan
2023-11-16 17:03           ` Mark Rutland
2023-11-16 17:03             ` Mark Rutland

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=CANk7y0g8SOrSAY2jqZ22v6Duu9yhHY-d39g5gJ2vA2j2Y-v53Q@mail.gmail.com \
    --to=puranjay12@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=will@kernel.org \
    --cc=yonghong.song@linux.dev \
    --cc=zlim.lnx@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.