mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chuyi Zhou <zhouchuyi@bytedance.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org, martin.lau@kernel.org, tj@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 6/7] bpf: Let bpf_iter_task_new accept null task ptr
Date: Sun, 1 Oct 2023 16:30:59 +0800	[thread overview]
Message-ID: <4e496d8c-437b-0aa8-5f23-9dbf29754d37@bytedance.com> (raw)
In-Reply-To: <CAEf4BzZKR7OXtpxak2ye5hsF3w9k8VLQb2u-dwGQQgqVG1sx+w@mail.gmail.com>

Hello,

在 2023/9/28 07:37, Andrii Nakryiko 写道:
> On Mon, Sep 25, 2023 at 3:56 AM Chuyi Zhou <zhouchuyi@bytedance.com> wrote:
>>
>> When using task_iter to iterate all threads of a specific task, we enforce
>> that the user must pass a valid task pointer to ensure safety. However,
>> when iterating all threads/process in the system, BPF verifier still
>> require a valid ptr instead of "nullable" pointer, even though it's
>> pointless, which is a kind of surprising from usability standpoint. It
>> would be nice if we could let that kfunc accept a explicit null pointer
>> when we are using BPF_TASK_ITER_ALL/BPF_TASK_ITER_PROC and a valid pointer
>> when using BPF_TASK_ITER_THREAD.
>>
>> Given a trival kfunc:
>>          __bpf_kfunc void FN(struct TYPE_A *obj)
>>
>> BPF Prog would reject a nullptr for obj. The error info is:
>> "arg#x pointer type xx xx must point to scalar, or struct with scalar"
>> reported by get_kfunc_ptr_arg_type(). The reg->type is SCALAR_VALUE and
>> the btf type of ref_t is not scalar or scalar_struct which leads to the
>> rejection of get_kfunc_ptr_arg_type.
>>
>> This patch reuse the __opt annotation which was used to indicate that
>> the buffer associated with an __sz or __szk argument may be null:
>>          __bpf_kfunc void FN(struct TYPE_A *obj__opt)
>> Here __opt indicates obj can be optional, user can pass a explicit nullptr
>> or a normal TYPE_A pointer. In get_kfunc_ptr_arg_type(), we will detect
>> whether the current arg is optional and register is null, If so, return
>> a new kfunc_ptr_arg_type KF_ARG_PTR_TO_NULL and skip to the next arg in
>> check_kfunc_args().
>>
>> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>
>> ---
>>   kernel/bpf/task_iter.c |  7 +++++--
>>   kernel/bpf/verifier.c  | 13 ++++++++++++-
>>   2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
>> index 9bcd3f9922b1..7ac007f161cc 100644
>> --- a/kernel/bpf/task_iter.c
>> +++ b/kernel/bpf/task_iter.c
>> @@ -867,7 +867,7 @@ struct bpf_iter_task_kern {
>>          unsigned int type;
>>   } __attribute__((aligned(8)));
>>
>> -__bpf_kfunc int bpf_iter_task_new(struct bpf_iter_task *it, struct task_struct *task, unsigned int type)
>> +__bpf_kfunc int bpf_iter_task_new(struct bpf_iter_task *it, struct task_struct *task__opt, unsigned int type)
>>   {
>>          struct bpf_iter_task_kern *kit = (void *)it;
>>          BUILD_BUG_ON(sizeof(struct bpf_iter_task_kern) != sizeof(struct bpf_iter_task));
>> @@ -877,14 +877,17 @@ __bpf_kfunc int bpf_iter_task_new(struct bpf_iter_task *it, struct task_struct *
>>          switch (type) {
>>          case BPF_TASK_ITER_ALL:
>>          case BPF_TASK_ITER_PROC:
>> +               break;
>>          case BPF_TASK_ITER_THREAD:
>> +               if (!task__opt)
>> +                       return -EINVAL;
>>                  break;
>>          default:
>>                  return -EINVAL;
>>          }
>>
>>          if (type == BPF_TASK_ITER_THREAD)
>> -               kit->task = task;
>> +               kit->task = task__opt;
>>          else
>>                  kit->task = &init_task;
>>          kit->pos = kit->task;
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index a065e18a0b3a..a79204c75a90 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -10331,6 +10331,7 @@ enum kfunc_ptr_arg_type {
>>          KF_ARG_PTR_TO_CALLBACK,
>>          KF_ARG_PTR_TO_RB_ROOT,
>>          KF_ARG_PTR_TO_RB_NODE,
>> +       KF_ARG_PTR_TO_NULL,
>>   };
>>
>>   enum special_kfunc_type {
>> @@ -10425,6 +10426,12 @@ static bool is_kfunc_bpf_rcu_read_unlock(struct bpf_kfunc_call_arg_meta *meta)
>>          return meta->func_id == special_kfunc_list[KF_bpf_rcu_read_unlock];
>>   }
>>
>> +static inline bool is_kfunc_arg_optional_null(struct bpf_reg_state *reg,
>> +                               const struct btf *btf, const struct btf_param *arg)
>> +{
>> +       return register_is_null(reg) && is_kfunc_arg_optional(btf, arg);
>> +}
>> +
>>   static enum kfunc_ptr_arg_type
>>   get_kfunc_ptr_arg_type(struct bpf_verifier_env *env,
>>                         struct bpf_kfunc_call_arg_meta *meta,
>> @@ -10497,6 +10504,8 @@ get_kfunc_ptr_arg_type(struct bpf_verifier_env *env,
>>           */
>>          if (!btf_type_is_scalar(ref_t) && !__btf_type_is_scalar_struct(env, meta->btf, ref_t, 0) &&
>>              (arg_mem_size ? !btf_type_is_void(ref_t) : 1)) {
>> +                       if (is_kfunc_arg_optional_null(reg, meta->btf, &args[argno]))
>> +                               return KF_ARG_PTR_TO_NULL;
> 
> This nested check seems misplaced. Maybe we shouldn't reuse __opt
> suffix which already has a different meaning (coupled with __sz). Why
> not add "__nullable" convention and just check it separately?
> 

IIUC, do you mean:

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index dbba2b806017..05d197365fcb 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -10458,6 +10458,8 @@ get_kfunc_ptr_arg_type(struct bpf_verifier_env *env,
         if (is_kfunc_arg_callback(env, meta->btf, &args[argno]))
                 return KF_ARG_PTR_TO_CALLBACK;

+       if (is_kfunc_arg_nullable(meta->btf, &args[argno]) && 
register_is_null(reg))
+               return KF_ARG_PTR_TO_NULL;

         if (argno + 1 < nargs &&
             (is_kfunc_arg_mem_size(meta->btf, &args[argno + 1], 
&regs[regno + 1]) ||


OK, I would change in next version.

Thanks.


  reply	other threads:[~2023-10-01  8:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25 10:55 [PATCH bpf-next v3 0/7] Add Open-coded task, css_task and css iters Chuyi Zhou
2023-09-25 10:55 ` [PATCH bpf-next v3 1/7] cgroup: Prepare for using css_task_iter_*() in BPF Chuyi Zhou
2023-09-25 10:55 ` [PATCH bpf-next v3 2/7] bpf: Introduce css_task open-coded iterator kfuncs Chuyi Zhou
2023-09-25 10:55 ` [PATCH bpf-next v3 3/7] bpf: Introduce task open coded " Chuyi Zhou
2023-09-27 23:20   ` Andrii Nakryiko
2023-09-28  3:29     ` Chuyi Zhou
2023-09-29 21:27       ` Andrii Nakryiko
2023-10-01  8:21         ` Chuyi Zhou
2023-10-03 22:05           ` Andrii Nakryiko
2023-09-25 10:55 ` [PATCH bpf-next v3 4/7] bpf: Introduce css open-coded " Chuyi Zhou
2023-09-27 23:24   ` Andrii Nakryiko
2023-09-28  2:51     ` Chuyi Zhou
2023-09-29 21:29       ` Andrii Nakryiko
2023-09-25 10:55 ` [PATCH bpf-next v3 5/7] bpf: teach the verifier to enforce css_iter and task_iter in RCU CS Chuyi Zhou
2023-09-27 10:00   ` Yafang Shao
2023-09-27 10:16     ` Chuyi Zhou
2023-09-27 23:29   ` Andrii Nakryiko
2023-09-25 10:55 ` [PATCH bpf-next v3 6/7] bpf: Let bpf_iter_task_new accept null task ptr Chuyi Zhou
2023-09-27 23:37   ` Andrii Nakryiko
2023-10-01  8:30     ` Chuyi Zhou [this message]
2023-09-25 10:55 ` [PATCH bpf-next v3 7/7] selftests/bpf: Add tests for open-coded task and css iter Chuyi Zhou
2023-09-25 18:48 ` [PATCH bpf-next v3 0/7] Add Open-coded task, css_task and css iters Tejun Heo

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=4e496d8c-437b-0aa8-5f23-9dbf29754d37@bytedance.com \
    --to=zhouchuyi@bytedance.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=tj@kernel.org \
    /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

all inboxes | Powered by JetHome®