From: Yonghong Song <yhs@meta.com>
To: Martin KaFai Lau <martin.lau@linux.dev>, 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 17:06:54 -0800 [thread overview]
Message-ID: <200910d3-23f2-e7e0-a03a-85d781d7341a@meta.com> (raw)
In-Reply-To: <3ee3af12-0542-e33c-2e9b-c6838de6ba64@linux.dev>
On 11/22/22 4:24 PM, Martin KaFai Lau wrote:
> 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?
Currently MEM_ALLOC is returned by bpf_obj_new() which takes prog btf.
currently MEM_RCU is only enabled with btf_struct_access() for
vmlinux btf. So if MEM_ALLOC is in reg->type, then MEM_RCU
should not appear.
But I guess we could still use is_trusted_reg() here since it
does cover the use case 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?
We should be okay here. flag is a local variable. It is used in
below function when reg_type is not SCALAR_VALUE.
static void mark_btf_ld_reg(struct bpf_verifier_env *env,
struct bpf_reg_state *regs, u32 regno,
enum bpf_reg_type reg_type,
struct btf *btf, u32 btf_id,
enum bpf_type_flag flag)
{
if (reg_type == SCALAR_VALUE) {
mark_reg_unknown(env, regs, regno);
return;
}
mark_reg_known_zero(env, regs, regno);
regs[regno].type = PTR_TO_BTF_ID | flag;
regs[regno].btf = btf;
regs[regno].btf_id = btf_id;
}
>
> [ ... ]
>
>> @@ -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?
Do we still care about ld_abs??
Actually I added this since spin_lock excludes this. But taking a deep
look at the function convert_bpf_ld_abs, it is converted to a bunch of
bpf insns and bpf_skb_load_helper_{8,16,32}() which eventually calls
skb_copy_bits(). Checking skb_copy_bits(), it seems the function is not
sleepable. Will remove this in the next revision.
>
> Others lgtm.
next prev parent reply other threads:[~2022-11-23 1:07 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
2022-11-23 1:06 ` Yonghong Song [this message]
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=200910d3-23f2-e7e0-a03a-85d781d7341a@meta.com \
--to=yhs@meta.com \
--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=martin.lau@linux.dev \
--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