On 8/18/17 4:51 PM, Daniel Borkmann wrote:
Lets future proof htab lookup inlining, commit 9015d2f59535 ("bpf: inline htab_map_lookup_elem()") was making the assumption that a direct call emission to __htab_map_lookup_elem() will always work out for JITs. This is currently true since all JITs we have are for 64 bit archs, but in case of 32 bit JITs like upcoming arm32, we get a NULL pointer dereference when executing the call to __htab_map_lookup_elem() since passed arguments are of a different size (unsigned long vs. u64 for pointers) than what we do out of BPF. Thus, lets do a proper BPF_CALL_2() declaration such that we don't need to make any such assumptions.Reported-by: Shubham Bansal <illusionist....@gmail.com> Signed-off-by: Daniel Borkmann <dan...@iogearbox.net>
assuming on 64-bit archs the should be no perf difference and only increase in .text, since __htab_map_lookup_elem is now force inlined into a bunch of places? I guess that's ok, but kinda sux for 64-bit archs to pay such penalty because of 32-bit archs. May be drop always_inline and do such thing conditionally on 32-bit archs only? what's the increase in .text? any difference seen in map_perf_test?
