All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Mark Rutland <mark.rutland@arm.com>, Hou Tao <houtao1@huawei.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Song Liu <songliubraving@fb.com>,
	"David S . Miller" <davem@davemloft.net>,
	John Fastabend <john.fastabend@gmail.com>,
	<netdev@vger.kernel.org>, <bpf@vger.kernel.org>,
	Zi Shen Lim <zlim.lnx@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Julien Thierry <jthierry@redhat.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH bpf-next 2/2] arm64, bpf: support more atomic operations
Date: Fri, 28 Jan 2022 08:15:09 -0800	[thread overview]
Message-ID: <03a72767-37bb-2d6f-0553-5a55571e09bd@fb.com> (raw)
In-Reply-To: <YfPCkUW4XIHGTZ6z@FVFF77S0Q05N>



On 1/28/22 2:16 AM, Mark Rutland wrote:
> On Fri, Jan 21, 2022 at 09:56:32PM +0800, Hou Tao wrote:
>> Atomics for eBPF patch series adds support for atomic[64]_fetch_add,
>> atomic[64]_[fetch_]{and,or,xor} and atomic[64]_{xchg|cmpxchg}, but
>> it only add support for x86-64, so support these atomic operations
>> for arm64 as well.
> 
> What ordering semantics are the BPF atomics supposed to have?
> 
> e.g. are those meant to be sequentially consistent, entirely relaxed, or
> somewhere imbetween?

The ordering semantics follows linux kernel memory model. Please
see interpreter implementation at kernel/bpf/core.c. The kernel
atomic_*() functions are used to implement these functions.

> 
>> Basically the implementation procedure is almost mechanical translation
>> of code snippets in atomic_ll_sc.h & atomic_lse.h & cmpxchg.h located
>> under arch/arm64/include/asm. An extra temporary register is needed
>> for (BPF_ADD | BPF_FETCH) to save the value of src register, instead of
>> adding TMP_REG_4 just use BPF_REG_AX instead.
>>
>> For cpus_have_cap(ARM64_HAS_LSE_ATOMICS) case and no-LSE-ATOMICS case,
>> both ./test_verifier and "./test_progs -t atomic" are exercised and
>> passed correspondingly.
>>
>> Signed-off-by: Hou Tao <houtao1@huawei.com>
>> ---
>>   arch/arm64/include/asm/insn.h |  45 +++++--
>>   arch/arm64/lib/insn.c         | 155 +++++++++++++++++++++---
> 
[...]

WARNING: multiple messages have this Message-ID (diff)
From: Yonghong Song <yhs@fb.com>
To: Mark Rutland <mark.rutland@arm.com>, Hou Tao <houtao1@huawei.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Song Liu <songliubraving@fb.com>,
	"David S . Miller" <davem@davemloft.net>,
	John Fastabend <john.fastabend@gmail.com>,
	<netdev@vger.kernel.org>, <bpf@vger.kernel.org>,
	Zi Shen Lim <zlim.lnx@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Julien Thierry <jthierry@redhat.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH bpf-next 2/2] arm64, bpf: support more atomic operations
Date: Fri, 28 Jan 2022 08:15:09 -0800	[thread overview]
Message-ID: <03a72767-37bb-2d6f-0553-5a55571e09bd@fb.com> (raw)
In-Reply-To: <YfPCkUW4XIHGTZ6z@FVFF77S0Q05N>



On 1/28/22 2:16 AM, Mark Rutland wrote:
> On Fri, Jan 21, 2022 at 09:56:32PM +0800, Hou Tao wrote:
>> Atomics for eBPF patch series adds support for atomic[64]_fetch_add,
>> atomic[64]_[fetch_]{and,or,xor} and atomic[64]_{xchg|cmpxchg}, but
>> it only add support for x86-64, so support these atomic operations
>> for arm64 as well.
> 
> What ordering semantics are the BPF atomics supposed to have?
> 
> e.g. are those meant to be sequentially consistent, entirely relaxed, or
> somewhere imbetween?

The ordering semantics follows linux kernel memory model. Please
see interpreter implementation at kernel/bpf/core.c. The kernel
atomic_*() functions are used to implement these functions.

> 
>> Basically the implementation procedure is almost mechanical translation
>> of code snippets in atomic_ll_sc.h & atomic_lse.h & cmpxchg.h located
>> under arch/arm64/include/asm. An extra temporary register is needed
>> for (BPF_ADD | BPF_FETCH) to save the value of src register, instead of
>> adding TMP_REG_4 just use BPF_REG_AX instead.
>>
>> For cpus_have_cap(ARM64_HAS_LSE_ATOMICS) case and no-LSE-ATOMICS case,
>> both ./test_verifier and "./test_progs -t atomic" are exercised and
>> passed correspondingly.
>>
>> Signed-off-by: Hou Tao <houtao1@huawei.com>
>> ---
>>   arch/arm64/include/asm/insn.h |  45 +++++--
>>   arch/arm64/lib/insn.c         | 155 +++++++++++++++++++++---
> 
[...]

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

  reply	other threads:[~2022-01-28 16:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-21 13:56 [PATCH bpf-next 0/2] arm64, bpf: support more atomic ops Hou Tao
2022-01-21 13:56 ` Hou Tao
2022-01-21 13:56 ` [PATCH bpf-next 1/2] selftests/bpf: use raw_tp program for atomic test Hou Tao
2022-01-21 13:56   ` Hou Tao
2022-01-21 17:43   ` Andrii Nakryiko
2022-01-21 17:43     ` Andrii Nakryiko
2022-01-21 13:56 ` [PATCH bpf-next 2/2] arm64, bpf: support more atomic operations Hou Tao
2022-01-21 13:56   ` Hou Tao
2022-01-27  6:06   ` John Fastabend
2022-01-27  6:06     ` John Fastabend
2022-01-27  8:10     ` Hou Tao
2022-01-27  8:10       ` Hou Tao
2022-01-28  2:43       ` John Fastabend
2022-01-28  2:43         ` John Fastabend
2022-01-28  9:18         ` Hou Tao
2022-01-28  9:18           ` Hou Tao
2022-01-28 10:06   ` Daniel Borkmann
2022-01-28 10:06     ` Daniel Borkmann
2022-01-28 10:16   ` Mark Rutland
2022-01-28 10:16     ` Mark Rutland
2022-01-28 16:15     ` Yonghong Song [this message]
2022-01-28 16:15       ` Yonghong Song

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=03a72767-37bb-2d6f-0553-5a55571e09bd@fb.com \
    --to=yhs@fb.com \
    --cc=andrii@kernel.org \
    --cc=ardb@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=houtao1@huawei.com \
    --cc=john.fastabend@gmail.com \
    --cc=jthierry@redhat.com \
    --cc=kafai@fb.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=will@kernel.org \
    --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.