On 3/6/25 07:50, Andrii Nakryiko wrote:
> On Wed, May 28, 2025 at 7:56 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
>>
>>
>>
>> On 28/5/25 06:31, Andrii Nakryiko wrote:
>>> Adding libbpf-rs maintainer, Daniel, for awareness, as Rust skeleton
>>> will have to add support for this, once this patch set lands upstream.
>>>
>>>
>>
>> [...]
>>
>>>> +
>>>> + if (map_cnt) {
>>>> + bpf_object__for_each_map(map, obj) {
>>>> + if (bpf_map__is_internal_percpu(map) &&
>>>> + get_map_ident(map, ident, sizeof(ident)))
>>>> + printf("\tobj->%s = NULL;\n", ident);
>>>> + }
>>>> + }
>>>
>>> hm... maybe we can avoid this by making libbpf re-mmap() this
>>> initialization image to be read-only during bpf_object load? Then the
>>> pointer can stay in the skeleton and be available for querying of
>>> "initialization values" (if anyone cares), and we won't have any extra
>>> post-processing steps in code generated skeleton code?
>>>
>>> And Rust skeleton will be able to expose this as a non-mutable
>>> reference with no extra magic behind it?
>>>
>>>
>> We can re-mmap() it as read-only.
>>
>> However, in the case of the Rust skeleton, users could still use unsafe
>> code to cast immutable variables to mutable ones.
>
> you have to actively want to abuse the API to do this, so I wouldn't
> be too concerned about this
>
Agreed.
It will be marked as read-only using mprotect().
Thanks,
Leon
