Re: [PATCH bpf-next v3] bpftool: Compute map size of light skeletons at runtime

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] bpf: compilation failure in skel_internal.h due to non-standard roundup macro
--

commit cf9410def9715a95832e67f7002ebd4dabf2d7ad
Author: Leon Hwang <leon.hwang@linux.dev>

bpftool: Compute map size of light skeletons at runtime

This commit addresses an issue with generating light skeletons on
a host with a different page size from the target. It accomplishes
this by passing the original map dimensions and dynamically computing
the mmap size at runtime.

> diff --git a/tools/lib/bpf/skel_internal.h b/tools/lib/bpf/skel_internal.h
> index 1f3f332dffbe9..9e16b8e8cb7c9 100644
> --- a/tools/lib/bpf/skel_internal.h
> +++ b/tools/lib/bpf/skel_internal.h
[ ... ]
> @@ -193,25 +197,39 @@ static inline void skel_free(void *p)
>  	free(p);
>  }
>  
> -static inline void skel_free_map_data(void *p, __u64 addr, size_t sz)
> +static inline size_t skel_map_mmap_sz(size_t val_sz, __u32 max_entries)
>  {
> -	munmap(p, sz);
> +	const long page_sz = sysconf(_SC_PAGE_SIZE);
> +	size_t mmap_sz;
> +
> +	mmap_sz = roundup(val_sz, 8) * max_entries;
> +	mmap_sz = roundup(mmap_sz, page_sz);

[Severity: Low]
Does this code rely on the non-standard roundup macro from <sys/param.h>?

When users include the generated light skeleton header in a project compiled
with strict C standards (e.g., -std=c99 or -std=c11) without _DEFAULT_SOURCE
or _GNU_SOURCE, the roundup macro might not be defined. This can cause a
compilation error due to an implicit declaration of function.

> +	return mmap_sz;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915161450.96249-1-leon.hwang@linux.dev?part=1