Hi, On 10/23/2024 3:30 PM, Byeonguk Jeong wrote: > On Wed, Oct 23, 2024 at 10:03:44AM +0800, Hou Tao wrote: >> Without the fix, there will be KASAN report as show below when dumping >> all keys in the lpm-trie through bpf_map_get_next_key(). > Thank you for testing. Alexei suggested adding a bpf self-test for the patch. I think you could reference the code in lpm_trie_map_batch_ops.c [1] or similar and add a new file that uses bpf_map_get_next_key to demonstrate the out-of-bound problem. The test can be run by ./test_maps. There is some document for the procedure in [2]. [1]: tools/testing/selftests/bpf/map_tests/lpm_trie_map_batch_ops.c [2]: https://github.com/torvalds/linux/blob/master/Documentation/bpf/bpf_devel_QA.rst > >> However, I have a dumb question: does it make sense to reject the >> element with prefixlen = 0 ? Because I can't think of a use case where a >> zero-length prefix will be useful. > With prefixlen = 0, it would always return -ENOENT, I think. Maybe it is > good to reject it earlier! > > . Which procedure will return -ENOENT ? I think the element with prefixlen=0 could still be found through the key with prefixlen = 0.
