[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP01T77PTK+bD2mBrxJShKNPhEypT2+nSHcr3=uuJbrghv_wFg@mail.gmail.com>
Date: Tue, 18 Oct 2022 07:23:23 +0530
From: Kumar Kartikeya Dwivedi <memxor@...il.com>
To: David Vernet <void@...ifault.com>
Cc: bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org,
yhs@...com, john.fastabend@...il.com, kpsingh@...nel.org,
sdf@...gle.com, haoluo@...gle.com, jolsa@...nel.org,
linux-kernel@...r.kernel.org, kernel-team@...com, tj@...nel.org
Subject: Re: [PATCH v3 3/3] bpf/selftests: Add selftests for new task kfuncs
On Sat, 15 Oct 2022 at 01:45, David Vernet <void@...ifault.com> wrote:
>
> A previous change added a series of kfuncs for storing struct
> task_struct objects as referenced kptrs. This patch adds a new
> task_kfunc test suite for validating their expected behavior.
>
> Signed-off-by: David Vernet <void@...ifault.com>
> ---
> [...]
> +
> +SEC("tp_btf/task_newtask")
> +int BPF_PROG(task_kfunc_acquire_trusted_nested, struct task_struct *task, u64 clone_flags)
> +{
> + struct task_struct *acquired;
> +
> + if (!is_test_kfunc_task())
> + return 0;
> +
> + /* Can't invoke bpf_task_acquire() on a trusted pointer at a nonzero offset. */
> + acquired = bpf_task_acquire(task->last_wakee);
The comment is incorrect, that would be &task->last_wakee instead,
this is PTR_TO_BTF_ID | PTR_NESTED.
> + if (!acquired)
> + return 0;
> + bpf_task_release(acquired);
> +
> + return 0;
> +}
> +
> [...]
> +
> +static int test_acquire_release(struct task_struct *task)
> +{
> + struct task_struct *acquired;
> +
> + acquired = bpf_task_acquire(task);
Unfortunately a side effect of this change is that now since
PTR_TO_BTF_ID without ref_obj_id is considered trusted, the bpf_ct_*
functions would begin working with tp_btf args. That probably needs to
be fixed so that they reject them (ideally with a failing test case to
make sure it doesn't resurface), probably with a new suffix __ref/or
__owned as added here [0].
Alexei, since you've suggested avoiding adding that suffix, do you see
any other way out here?
It's questionable whether bpf_ct_set_timeout/status should work for CT
not owned by the BPF program.
[0]: https://lore.kernel.org/bpf/dfb859a6b76a9234baa194e795ae89cb7ca5694b.1662383493.git.lorenzo@kernel.org
> + if (!acquired) {
> + err = 1;
> + return 0;
> + }
> +
> + bpf_task_release(acquired);
> +
> + return 0;
> +}
> +
> [...]
Powered by blists - more mailing lists