On Wed, Oct 9, 2024 at 10:45 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > > > > On 10/9/2024 2:30 AM, Andrii Nakryiko wrote: > > On Tue, Oct 8, 2024 at 2:05 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > >> From: Hou Tao <houtao1@xxxxxxxxxx> > >> > >> Under 32-bits host (e.g, arm32) , when a bpf program passes an u64 to > >> bpf_iter_bits_new(), bpf_iter_bits_new() will use bits_copy to save the > >> content of the u64, but the size of bits_copy is only 4-bytes, and there > >> will be stack corruption. > >> > >> Fix it by change the type of unsafe_ptr from u64 * to unsigned long *. > >> > > This will be confusing as BPF-side long is always 64-bit. So why not > > instead make sure it's u64 throughout (i.e., bits_copy is u64 > > explicitly), even on 32-bit architectures? > > Just learn about the size of BPF-side long is always 64-bits. I had > considered to change bits_copy to u64. The main obstacle is that the > pointer type of find_next_bit is unsigned long *, if it is used on an > u64 under big-endian host, it may return invalid result. IIUC, BPF targets only 64-bit systems? -- Regards Yafang
