[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJD0xLa=bWUerdYsRg8R4S54yqnPnuwkHWL1R663U3Xcg@mail.gmail.com>
Date: Fri, 14 Nov 2025 18:01:29 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Amery Hung <ameryhung@...il.com>
Cc: bpf <bpf@...r.kernel.org>, Network Development <netdev@...r.kernel.org>,
Andrii Nakryiko <andrii@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <martin.lau@...nel.org>, Kumar Kartikeya Dwivedi <memxor@...il.com>, KP Singh <kpsingh@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, Song Liu <song@...nel.org>,
Kernel Team <kernel-team@...a.com>
Subject: Re: [PATCH v2 bpf-next 4/4] bpf: Replace bpf memory allocator with
kmalloc_nolock() in local storage
On Fri, Nov 14, 2025 at 12:13 PM Amery Hung <ameryhung@...il.com> wrote:
>
>
> - if (smap->bpf_ma) {
> + if (smap->use_kmalloc_nolock) {
> rcu_barrier_tasks_trace();
> - if (!rcu_trace_implies_rcu_gp())
> - rcu_barrier();
> - bpf_mem_alloc_destroy(&smap->selem_ma);
> - bpf_mem_alloc_destroy(&smap->storage_ma);
> + rcu_barrier();
Why unconditional rcu_barrier() ?
It's implied in rcu_barrier_tasks_trace().
What am I missing?
The rest looks good.
If that's the only issue, I can fix it up while applying.
Powered by blists - more mailing lists