public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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