From: Martin KaFai Lau <martin.lau@linux.dev>
To: Yonghong Song <yhs@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>,
bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v8 3/4] bpf: Add kfunc bpf_rcu_read_lock/unlock()
Date: Tue, 22 Nov 2022 16:24:52 -0800 [thread overview]
Message-ID: <3ee3af12-0542-e33c-2e9b-c6838de6ba64@linux.dev> (raw)
In-Reply-To: <20221122195335.1782147-1-yhs@fb.com>
On 11/22/22 11:53 AM, Yonghong Song wrote:
> + if (flag & MEM_RCU) {
> + /* Mark value register as MEM_RCU only if it is protected by
> + * bpf_rcu_read_lock() and the ptr reg is trusted (PTR_TRUSTED or
> + * ref_obj_id != 0). MEM_RCU itself can already indicate
> + * trustedness inside the rcu read lock region. But Mark it
> + * as PTR_TRUSTED as well similar to MEM_ALLOC.
> + */
> + if (!env->cur_state->active_rcu_lock ||
> + (!(reg->type & PTR_TRUSTED) && !reg->ref_obj_id))
Can is_trusted_reg() be reused or MEM_ALLOC is not applicable here?
> + flag &= ~MEM_RCU;
> + else
> + flag |= PTR_TRUSTED;
> + } else if (reg->type & MEM_RCU) {
> + /* ptr (reg) is marked as MEM_RCU, but value reg is not marked as MEM_RCU.
> + * Mark the value reg as PTR_UNTRUSTED conservatively.
> + */
> + flag |= PTR_UNTRUSTED;
Should PTR_UNTRUSTED tagging be limited to ret == PTR_TO_BTF_ID instead of
tagging SCALAR also?
[ ... ]
> @@ -11754,6 +11840,11 @@ static int check_ld_abs(struct bpf_verifier_env *env, struct bpf_insn *insn)
> return -EINVAL;
> }
>
> + if (env->prog->aux->sleepable && env->cur_state->active_rcu_lock) {
I don't know the details about ld_abs :). Why sleepable check is needed here?
Others lgtm.
next prev parent reply other threads:[~2022-11-23 0:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 19:53 [PATCH bpf-next v8 0/4] bpf: Add bpf_rcu_read_lock() support Yonghong Song
2022-11-22 19:53 ` [PATCH bpf-next v8 1/4] compiler_types: Define __rcu as __attribute__((btf_type_tag("rcu"))) Yonghong Song
2022-11-22 19:53 ` [PATCH bpf-next v8 2/4] bpf: Introduce might_sleep field in bpf_func_proto Yonghong Song
2022-11-22 19:53 ` [PATCH bpf-next v8 3/4] bpf: Add kfunc bpf_rcu_read_lock/unlock() Yonghong Song
2022-11-23 0:24 ` Martin KaFai Lau [this message]
2022-11-23 1:06 ` Yonghong Song
2022-11-23 1:19 ` Martin KaFai Lau
2022-11-23 1:24 ` Yonghong Song
2022-11-22 19:53 ` [PATCH bpf-next v8 4/4] selftests/bpf: Add tests for bpf_rcu_read_lock() Yonghong Song
2022-11-23 0:56 ` Martin KaFai Lau
2022-11-23 1:13 ` Yonghong Song
2022-11-23 1:39 ` Martin KaFai Lau
2022-11-23 1:52 ` Martin KaFai Lau
[not found] ` <SN6PR1501MB20649F820B6FFE58166817E5CA0C9@SN6PR1501MB2064.namprd15.prod.outlook.com>
2022-11-23 23:13 ` Martin KaFai Lau
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=3ee3af12-0542-e33c-2e9b-c6838de6ba64@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox