On Sun, Dec 17, 2023 at 10:30:47PM -0800, Yonghong Song wrote:
> @@ -2963,7 +2963,9 @@ static int __init bpf_global_ma_init(void)
>
> ret = bpf_mem_alloc_init(&bpf_global_ma, 0, false);
> bpf_global_ma_set = !ret;
> - return ret;
> + ret = bpf_mem_alloc_percpu_init(&bpf_global_percpu_ma);
> + bpf_global_percpu_ma_set = !ret;
> + return !bpf_global_ma_set || !bpf_global_percpu_ma_set;
...
> - if (meta.func_id == special_kfunc_list[KF_bpf_percpu_obj_new_impl]) {
> - if (!bpf_global_percpu_ma_set) {
> - mutex_lock(&bpf_percpu_ma_lock);
> - if (!bpf_global_percpu_ma_set) {
> - err = bpf_mem_alloc_init(&bpf_global_percpu_ma, 0, true);
> - if (!err)
> - bpf_global_percpu_ma_set = true;
> - }
> - mutex_unlock(&bpf_percpu_ma_lock);
> - if (err)
> - return err;
> - }
> - }
> -
> if (((u64)(u32)meta.arg_constant.value) != meta.arg_constant.value) {
> verbose(env, "local type ID argument must be in range [0, U32_MAX]\n");
> return -EINVAL;
> @@ -12096,6 +12079,17 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> return -EINVAL;
> }
>
> + if (meta.func_id == special_kfunc_list[KF_bpf_percpu_obj_new_impl]) {
> + if (!bpf_global_percpu_ma_set)
> + return -ENOMEM;
The patch set looks great except I don't understand this part of the patch
that goes back to allocating bpf_global_percpu_ma by default.
Why allocate even small amount if no bpf prog will use it?
It seems delaying allocation until the verifier sees the need is better.
The rest of the series makes sense.
