You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the documentation for eBPF hash maps (https://docs.kernel.org/bpf/map_hash.html), an LRU hash map is expected to evict the least recently used item when attempting to insert an element when the map is full.
Tracee uses a few small capacity LRU hash maps (io_file_path_cache_map, elf_files_map, recent_deleted_module_map). They should be reviewed to make sure that they don't rely on incorrect assumptions about the behavior of the LRU map.
The text was updated successfully, but these errors were encountered:
__bpf_lru_list_shrink_inactive() will evict a node batch. It will depend on the type of the map, if local (LOCAL_FREE_TARGET), 128, if percpu (PERCPU_FREE_TARGET), 4.
Since it's a special LRU and we can't count with the removal of a single element per eviction triggered, one possibility is to convert the local map to a percpu type trying at least to reduce the removed batch.
According to the documentation for eBPF hash maps (https://docs.kernel.org/bpf/map_hash.html), an LRU hash map is expected to evict the least recently used item when attempting to insert an element when the map is full.
Despite this description, the implementation for the LRU hash map behaves in a way that causes maps with a small number of max entries to behave unexpectedly. See https://stackoverflow.com/questions/75882443/elements-incorrectly-evicted-from-ebpf-lru-hash-map for an example and discussion.
Tracee uses a few small capacity LRU hash maps (
io_file_path_cache_map
,elf_files_map
,recent_deleted_module_map
). They should be reviewed to make sure that they don't rely on incorrect assumptions about the behavior of the LRU map.The text was updated successfully, but these errors were encountered: