On Wed, Aug 2, 2023 at 8:46 AM David Vernet <void@xxxxxxxxxxxxx> wrote: > > On Tue, Aug 01, 2023 at 11:54:18PM -0700, Yonghong Song wrote: > > > > > > On 8/1/23 8:29 PM, David Vernet wrote: > > > On Tue, Aug 01, 2023 at 07:45:57PM -0700, Alexei Starovoitov wrote: > > > > On Tue, Aug 1, 2023 at 7:34 PM Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > In kernel, we have a global variable > > > > > > nr_cpu_ids (also in kernel/bpf/helpers.c) > > > > > > which is used in numerous places for per cpu data struct access. > > > > > > > > > > > > I am wondering whether we could have bpf code like > > > > > > int nr_cpu_ids __ksym; > > > > > > I think this would be useful in general, though any __ksym variable like > > > this would have to be const and mapped in .rodata, right? But yeah, > > > being able to R/O map global variables like this which have static > > > lifetimes would be nice. > > > > No. There is no map here. __ksym symbol will have a ld_imm64 insn > > to load the value in the bpf code. The address will be the kernel > > address patched by libbpf. > > ld_imm64 is fine. I'm talking about stores. BPF progs should not be able > to mutate these variables. ksyms are readonly and support for them is already in the kernel and libbpf. The only reason: extern int nr_cpu_ids __ksym; doesn't work today because nr_cpu_ids is not in vmlinux BTF. pahole adds only per-cpu vars to BTF.
