On Wed, Oct 9, 2024 at 4:40 AM Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > 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? 64-bit bpf programs run just fine on 32-bit systems.
