All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Puranjay Mohan <puranjay12@gmail.com>,
	Florent Revest <revest@chromium.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	bpf <bpf@vger.kernel.org>, KP Singh <kpsingh@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v4 0/3] bpf, arm64: use BPF prog pack allocator in BPF JIT
Date: Thu, 2 Nov 2023 15:59:52 +0000	[thread overview]
Message-ID: <ZUPHeEe1eJjHkhsg@FVFF77S0Q05N.cambridge.arm.com> (raw)
In-Reply-To: <ZMuLvKRbPfOK0IpN@FVFF77S0Q05N>

On Thu, Aug 03, 2023 at 12:13:00PM +0100, Mark Rutland wrote:
[...]

> However, in looking at it I think
> there may me a wider potential isssue w.r.t. the way instruction memory gets
> reused, because as writtten today the architecture doesn't seem to have a
> guarantee on when instruction fetches are completed and therefore when it's
> safe to modify instruction memory. Usually we're saved by TLB maintenance,
> which this series avoids by design.

Just to confirm on this point specifically, per discussions with our
architects, the (architectural) execution of an instruction ensures that there
are no outstanding fetches for prior instructions. IIUC that will be clarified 
the next release of the ARM ARM.

So as long as we're certain all threads have left the old code (e.g. via a
flag, RCU tasks rude synchronization, whatever) before we overwrite slots in
the shared buffer, we should be good.

We will need to be very careful with the maintenance when installing new code
into the shared buffer (e.g. we will require an IPI to all other CPUs), but
that should be relatively simple.

I'll go review the latest patches with that in mind.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Puranjay Mohan <puranjay12@gmail.com>,
	Florent Revest <revest@chromium.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	bpf <bpf@vger.kernel.org>, KP Singh <kpsingh@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v4 0/3] bpf, arm64: use BPF prog pack allocator in BPF JIT
Date: Thu, 2 Nov 2023 15:59:52 +0000	[thread overview]
Message-ID: <ZUPHeEe1eJjHkhsg@FVFF77S0Q05N.cambridge.arm.com> (raw)
In-Reply-To: <ZMuLvKRbPfOK0IpN@FVFF77S0Q05N>

On Thu, Aug 03, 2023 at 12:13:00PM +0100, Mark Rutland wrote:
[...]

> However, in looking at it I think
> there may me a wider potential isssue w.r.t. the way instruction memory gets
> reused, because as writtten today the architecture doesn't seem to have a
> guarantee on when instruction fetches are completed and therefore when it's
> safe to modify instruction memory. Usually we're saved by TLB maintenance,
> which this series avoids by design.

Just to confirm on this point specifically, per discussions with our
architects, the (architectural) execution of an instruction ensures that there
are no outstanding fetches for prior instructions. IIUC that will be clarified 
the next release of the ARM ARM.

So as long as we're certain all threads have left the old code (e.g. via a
flag, RCU tasks rude synchronization, whatever) before we overwrite slots in
the shared buffer, we should be good.

We will need to be very careful with the maintenance when installing new code
into the shared buffer (e.g. we will require an IPI to all other CPUs), but
that should be relatively simple.

I'll go review the latest patches with that in mind.

Thanks,
Mark.

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

  parent reply	other threads:[~2023-11-02 16:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26  8:58 [PATCH bpf-next v4 0/3] bpf, arm64: use BPF prog pack allocator in BPF JIT Puranjay Mohan
2023-06-26  8:58 ` Puranjay Mohan
2023-06-26  8:58 ` [PATCH bpf-next v4 1/3] bpf: make bpf_prog_pack allocator portable Puranjay Mohan
2023-06-26  8:58   ` Puranjay Mohan
2023-06-26  8:58 ` [PATCH bpf-next v4 2/3] arm64: patching: Add aarch64_insn_copy() Puranjay Mohan
2023-06-26  8:58   ` Puranjay Mohan
2023-06-26  8:58 ` [PATCH bpf-next v4 3/3] bpf, arm64: use bpf_jit_binary_pack_alloc Puranjay Mohan
2023-06-26  8:58   ` Puranjay Mohan
2023-08-15 14:09   ` Puranjay Mohan
2023-08-15 14:09     ` Puranjay Mohan
2023-08-16 13:25     ` Daniel Borkmann
2023-08-16 13:25       ` Daniel Borkmann
2023-06-30 17:20 ` [PATCH bpf-next v4 0/3] bpf, arm64: use BPF prog pack allocator in BPF JIT Florent Revest
2023-06-30 17:20   ` Florent Revest
2023-07-03 16:40 ` Daniel Borkmann
2023-07-03 16:40   ` Daniel Borkmann
2023-07-03 17:15   ` Mark Rutland
2023-07-03 17:15     ` Mark Rutland
2023-07-03 17:54     ` Daniel Borkmann
2023-07-03 17:54       ` Daniel Borkmann
2023-07-17  7:50     ` Puranjay Mohan
2023-07-17  7:50       ` Puranjay Mohan
2023-07-30 17:22       ` Puranjay Mohan
2023-07-30 17:22         ` Puranjay Mohan
2023-08-02 21:02         ` Alexei Starovoitov
2023-08-02 21:02           ` Alexei Starovoitov
2023-08-03 11:13           ` Mark Rutland
2023-08-03 11:13             ` Mark Rutland
2023-08-03 16:15             ` Alexei Starovoitov
2023-08-03 16:15               ` Alexei Starovoitov
2023-08-03 16:32               ` Florent Revest
2023-08-03 16:32                 ` Florent Revest
2023-08-04 15:11             ` Puranjay Mohan
2023-08-04 15:11               ` Puranjay Mohan
2023-11-02 15:59             ` Mark Rutland [this message]
2023-11-02 15:59               ` 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=ZUPHeEe1eJjHkhsg@FVFF77S0Q05N.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=alexei.starovoitov@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=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=puranjay12@gmail.com \
    --cc=revest@chromium.org \
    --cc=song@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.