From: Puranjay Mohan <puranjay@kernel.org>
To: Michael Ellerman <mpe@ellerman.id.au>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
"Eduard Zingerman" <eddyz87@gmail.com>,
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>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Hari Bathini <hbathini@linux.ibm.com>,
bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH
Date: Wed, 08 May 2024 11:39:05 +0000 [thread overview]
Message-ID: <mb61pwmo4zg6e.fsf@kernel.org> (raw)
In-Reply-To: <87o79gopuj.fsf@mail.lhotse>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Puranjay Mohan <puranjay@kernel.org> writes:
>> The Linux Kernel Memory Model [1][2] requires RMW operations that have a
>> return value to be fully ordered.
>>
>> BPF atomic operations with BPF_FETCH (including BPF_XCHG and
>> BPF_CMPXCHG) return a value back so they need to be JITed to fully
>> ordered operations. POWERPC currently emits relaxed operations for
>> these.
>
> Thanks for catching this.
>
>> diff --git a/arch/powerpc/net/bpf_jit_comp32.c b/arch/powerpc/net/bpf_jit_comp32.c
>> index 2f39c50ca729..b635e5344e8a 100644
>> --- a/arch/powerpc/net/bpf_jit_comp32.c
>> +++ b/arch/powerpc/net/bpf_jit_comp32.c
>> @@ -853,6 +853,15 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct code
>> /* Get offset into TMP_REG */
>> EMIT(PPC_RAW_LI(tmp_reg, off));
>> tmp_idx = ctx->idx * 4;
>> + /*
>> + * Enforce full ordering for operations with BPF_FETCH by emitting a 'sync'
>> + * before and after the operation.
>> + *
>> + * This is a requirement in the Linux Kernel Memory Model.
>> + * See __cmpxchg_u64() in asm/cmpxchg.h as an example.
>> + */
>> + if (imm & BPF_FETCH)
>> + EMIT(PPC_RAW_SYNC());
>> /* load value from memory into r0 */
>> EMIT(PPC_RAW_LWARX(_R0, tmp_reg, dst_reg, 0));
>>
>> @@ -905,6 +914,8 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct code
>>
>> /* For the BPF_FETCH variant, get old data into src_reg */
>> if (imm & BPF_FETCH) {
>> + /* Emit 'sync' to enforce full ordering */
>> + EMIT(PPC_RAW_SYNC());
>> EMIT(PPC_RAW_MR(ret_reg, ax_reg));
>> if (!fp->aux->verifier_zext)
>> EMIT(PPC_RAW_LI(ret_reg - 1, 0)); /* higher 32-bit */
>
> On 32-bit there are non-SMP systems where those syncs will probably be expensive.
>
> I think just adding an IS_ENABLED(CONFIG_SMP) around the syncs is
> probably sufficient. Christophe?
Yes, I should do it for both 32-bit and 64-bit because the kernel does
that as well:
In POWERPC __atomic_pre/post_full_fence resolves to 'sync' in case of
CONFIG_SMP and barrier() in case of !CONFIG_SMP.
barrier() is not relevant for JITs as it is used at compile time.
So, I will use
if (IS_ENABLED(CONFIG_SMP))
EMIT(PPC_RAW_SYNC());
in the next version.
Thanks,
Puranjay
next prev parent reply other threads:[~2024-05-08 11:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 17:54 [PATCH bpf] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH Puranjay Mohan
2024-05-08 5:05 ` Michael Ellerman
2024-05-08 11:39 ` Puranjay Mohan [this message]
2024-05-13 6:10 ` Christophe Leroy
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=mb61pwmo4zg6e.fsf@kernel.org \
--to=puranjay@kernel.org \
--cc=andrii@kernel.org \
--cc=aneesh.kumar@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hbathini@linux.ibm.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=martin.lau@linux.dev \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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.