Re: [PATCH v4 bpf-next 2/4] libbpf: support libbpf-provided extern variables

[Daniel Borkmann <daniel@iogearbox.net>]

On 12/17/19 8:03 PM, Andrii Nakryiko wrote:
> On Tue, Dec 17, 2019 at 6:42 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 12/16/19 8:29 PM, Andrii Nakryiko wrote:
>>> On Mon, Dec 16, 2019 at 3:17 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>>> On Fri, Dec 13, 2019 at 05:47:08PM -0800, Andrii Nakryiko wrote:
[...]
>>> So for application-specific stuff, there isn't really a need to use
>>> externs to do that. Furthermore, I think allowing using externs as
>>> just another way to specify application-specific configuration is
>>> going to create a problem, potentially, as we'll have higher
>>> probability of collisions with kernel-provided extersn (variables
>>> and/or functions), or even externs provided by other
>>> dynamically/statically linked BPF programs (once we have dynamic and
>>> static linking, of course).
>>
>> Yes, that makes more sense, but then we are already potentially colliding
>> with current CONFIG_* variables once we handle dynamically / statically
>> linked BPF programs. Perhaps that's my confusion in the first place. Would
>> have been good if 166750bc1dd2 had a discussion on that as part of the
>> commit message.
>>
>> So, naive question, what's the rationale of not using .rodata variables
>> for CONFIG_* case and how do we handle these .extern collisions in future?
>> Should these vars rather have had some sort of annotation or be moved into
>> special ".extern.config" section or the like where we explicitly know that
>> these are handled differently so they don't collide with future ".extern"
>> content once we have linked BPF programs?
> 
> Yes, name collision is a possibility, which means users should
> restrain from using LINUX_KERNEL_VERSION and CONFIG_XXX names for
> their variables. But if that is ever actually the problem, the way to
> resolve this collision/ambiguity would be to put externs in a separate
> sections. It's possible to annotate extern variable with custom
> section.
> 
> But I guess putting Kconfig-provided externs into ".extern.kconfig"
> might be a good idea, actually. That will make it possible to have
> writable externs in the future.

Yep, and as mentioned it will make it more clear that these get special
loader treatment as opposed to regular externs we need to deal with in
future. A '.extern.kconfig' section sounds good to me and the BPF helper
header could provide a __kconfig annotation for that as well.