| Message ID | 157529025128.29832.5953245340679936909.stgit@firesoul |
|---|---|
| State | Accepted |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | [bpf] samples/bpf: fix broken xdp_rxq_info due to map order assumptions | expand |
Jesper Dangaard Brouer <brouer@redhat.com> writes: > In the days of using bpf_load.c the order in which the 'maps' sections > were defines in BPF side (*_kern.c) file, were used by userspace side > to identify the map via using the map order as an index. In effect the > order-index is created based on the order the maps sections are stored > in the ELF-object file, by the LLVM compiler. > > This have also carried over in libbpf via API bpf_map__next(NULL, obj) > to extract maps in the order libbpf parsed the ELF-object file. > > When BTF based maps were introduced a new section type ".maps" were > created. I found that the LLVM compiler doesn't create the ".maps" > sections in the order they are defined in the C-file. The order in the > ELF file is based on the order the map pointer is referenced in the code. > > This combination of changes lead to xdp_rxq_info mixing up the map > file-descriptors in userspace, resulting in very broken behaviour, but > without warning the user. > > This patch fix issue by instead using bpf_object__find_map_by_name() > to find maps via their names. (Note, this is the ELF name, which can > be longer than the name the kernel retains). > > Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf") > Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map") > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
On Mon, Dec 2, 2019 at 4:37 AM Jesper Dangaard Brouer <brouer@redhat.com> wrote: > > In the days of using bpf_load.c the order in which the 'maps' sections > were defines in BPF side (*_kern.c) file, were used by userspace side > to identify the map via using the map order as an index. In effect the > order-index is created based on the order the maps sections are stored > in the ELF-object file, by the LLVM compiler. > > This have also carried over in libbpf via API bpf_map__next(NULL, obj) > to extract maps in the order libbpf parsed the ELF-object file. > > When BTF based maps were introduced a new section type ".maps" were > created. I found that the LLVM compiler doesn't create the ".maps" > sections in the order they are defined in the C-file. The order in the > ELF file is based on the order the map pointer is referenced in the code. > > This combination of changes lead to xdp_rxq_info mixing up the map > file-descriptors in userspace, resulting in very broken behaviour, but > without warning the user. > > This patch fix issue by instead using bpf_object__find_map_by_name() > to find maps via their names. (Note, this is the ELF name, which can > be longer than the name the kernel retains). > > Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf") > Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map") > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> > --- > samples/bpf/xdp_rxq_info_user.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/samples/bpf/xdp_rxq_info_user.c b/samples/bpf/xdp_rxq_info_user.c > index 51e0d810e070..8fc3ad01de72 100644 > --- a/samples/bpf/xdp_rxq_info_user.c > +++ b/samples/bpf/xdp_rxq_info_user.c > @@ -489,9 +489,9 @@ int main(int argc, char **argv) > if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd)) > return EXIT_FAIL; > > - map = bpf_map__next(NULL, obj); > - stats_global_map = bpf_map__next(map, obj); > - rx_queue_index_map = bpf_map__next(stats_global_map, obj); > + map = bpf_object__find_map_by_name(obj, "config_map"); > + stats_global_map = bpf_object__find_map_by_name(obj, "stats_global_map"); > + rx_queue_index_map = bpf_object__find_map_by_name(obj, "rx_queue_index_map"); Yeah, relying on relative order of maps as instantiated by libbpf internally is extremely fragile. Thanks for fixing this. Acked-by: Andrii Nakryiko <andriin@fb.com> > if (!map || !stats_global_map || !rx_queue_index_map) { > printf("finding a map in obj file failed\n"); > return EXIT_FAIL; >
On Mon, Dec 2, 2019 at 4:37 AM Jesper Dangaard Brouer <brouer@redhat.com> wrote: > > In the days of using bpf_load.c the order in which the 'maps' sections > were defines in BPF side (*_kern.c) file, were used by userspace side > to identify the map via using the map order as an index. In effect the > order-index is created based on the order the maps sections are stored > in the ELF-object file, by the LLVM compiler. > > This have also carried over in libbpf via API bpf_map__next(NULL, obj) > to extract maps in the order libbpf parsed the ELF-object file. > > When BTF based maps were introduced a new section type ".maps" were > created. I found that the LLVM compiler doesn't create the ".maps" > sections in the order they are defined in the C-file. The order in the > ELF file is based on the order the map pointer is referenced in the code. > > This combination of changes lead to xdp_rxq_info mixing up the map > file-descriptors in userspace, resulting in very broken behaviour, but > without warning the user. > > This patch fix issue by instead using bpf_object__find_map_by_name() > to find maps via their names. (Note, this is the ELF name, which can > be longer than the name the kernel retains). > > Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf") > Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map") > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Applied. Thanks
diff --git a/samples/bpf/xdp_rxq_info_user.c b/samples/bpf/xdp_rxq_info_user.c index 51e0d810e070..8fc3ad01de72 100644 --- a/samples/bpf/xdp_rxq_info_user.c +++ b/samples/bpf/xdp_rxq_info_user.c @@ -489,9 +489,9 @@ int main(int argc, char **argv) if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd)) return EXIT_FAIL; - map = bpf_map__next(NULL, obj); - stats_global_map = bpf_map__next(map, obj); - rx_queue_index_map = bpf_map__next(stats_global_map, obj); + map = bpf_object__find_map_by_name(obj, "config_map"); + stats_global_map = bpf_object__find_map_by_name(obj, "stats_global_map"); + rx_queue_index_map = bpf_object__find_map_by_name(obj, "rx_queue_index_map"); if (!map || !stats_global_map || !rx_queue_index_map) { printf("finding a map in obj file failed\n"); return EXIT_FAIL;
In the days of using bpf_load.c the order in which the 'maps' sections were defines in BPF side (*_kern.c) file, were used by userspace side to identify the map via using the map order as an index. In effect the order-index is created based on the order the maps sections are stored in the ELF-object file, by the LLVM compiler. This have also carried over in libbpf via API bpf_map__next(NULL, obj) to extract maps in the order libbpf parsed the ELF-object file. When BTF based maps were introduced a new section type ".maps" were created. I found that the LLVM compiler doesn't create the ".maps" sections in the order they are defined in the C-file. The order in the ELF file is based on the order the map pointer is referenced in the code. This combination of changes lead to xdp_rxq_info mixing up the map file-descriptors in userspace, resulting in very broken behaviour, but without warning the user. This patch fix issue by instead using bpf_object__find_map_by_name() to find maps via their names. (Note, this is the ELF name, which can be longer than the name the kernel retains). Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf") Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map") Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> --- samples/bpf/xdp_rxq_info_user.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)