tequilaOS/platform_system_bpf
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

const-ify mapMatchesExpectations arguments am: 1a7fff3568 am: 9cfd5090df am: 38b068d821

Browse source 
Original change: https://android-review.googlesource.com/c/platform/system/bpf/+/2132835

Change-Id: Ib164e440de76e1873f03bbaadc53d0a18e0bfb83
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
This commit is contained in:
Maciej Żenczykowski 2022-06-24 19:59:55 +00:00 committed by Automerger Merge Worker
commit b1701ae197
1 changed files with 20 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
libbpf_android/Loader.cpp
View file

@ -638,8 +638,8 @@ static std::optional<unique_fd> getMapBtfInfo(const char* elfPath,
return btfFd;
}
static bool mapMatchesExpectations(unique_fd& fd, string& mapName, struct bpf_map_def& mapDef,
enum bpf_map_type type) {
static bool mapMatchesExpectations(const unique_fd& fd, const string& mapName,
const struct bpf_map_def& mapDef, const enum bpf_map_type type) {
// bpfGetFd... family of functions require at minimum a 4.14 kernel,
// so on 4.9 kernels just pretend the map matches our expectations.
// This isn't really a problem as we only really support 4.14+ anyway...
@ -649,13 +649,10 @@ static bool mapMatchesExpectations(unique_fd& fd, string& mapName, struct bpf_ma
// or a newly introduced kernel feature/bug (which is unlikely to get backported to 4.9).
if (!isAtLeastKernelVersion(4, 14, 0)) return true;
// These asserts should *never* trigger, if one of them somehow does,
// it probably means a bpf .o file has been changed/replaced at runtime
// and bpfloader was manually rerun (normally it should only run *once*
// early during the boot process).
// Another possibility is that something is misconfigured in the code:
// most likely a shared map is declared twice differently.
// But such a change should never be checked into the source tree...
// Assuming fd is a valid Bpf Map file descriptor then
// all the following should always succeed on a 4.14+ kernel.
// If they somehow do fail, they'll return -1 (and set errno),
// which should then cause (among others) a key_size mismatch.
int fd_type = bpfGetFdMapType(fd);
int fd_key_size = bpfGetFdKeySize(fd);
int fd_value_size = bpfGetFdValueSize(fd);
@ -668,14 +665,20 @@ static bool mapMatchesExpectations(unique_fd& fd, string& mapName, struct bpf_ma
if (type == BPF_MAP_TYPE_DEVMAP || type == BPF_MAP_TYPE_DEVMAP_HASH)
desired_map_flags |= BPF_F_RDONLY_PROG;
// If anything doesn't match, just close the fd - it's of no use anyway.
if (fd_type != type) fd.reset();
if (fd_key_size != (int)mapDef.key_size) fd.reset();
if (fd_value_size != (int)mapDef.value_size) fd.reset();
if (fd_max_entries != (int)mapDef.max_entries) fd.reset();
if (fd_map_flags != desired_map_flags) fd.reset();
if (fd.ok()) return true;
// The following checks should *never* trigger, if one of them somehow does,
// it probably means a bpf .o file has been changed/replaced at runtime
// and bpfloader was manually rerun (normally it should only run *once*
// early during the boot process).
// Another possibility is that something is misconfigured in the code:
// most likely a shared map is declared twice differently.
// But such a change should never be checked into the source tree...
if ((fd_type == type) &&
(fd_key_size == (int)mapDef.key_size) &&
(fd_value_size == (int)mapDef.value_size) &&
(fd_max_entries == (int)mapDef.max_entries) &&
(fd_map_flags == desired_map_flags)) {
return true;
}
ALOGE("bpf map name %s mismatch: desired/found: "
"type:%d/%d key:%u/%d value:%u/%d entries:%u/%d flags:%u/%d",