service bpfloader /system/bin/bpfloader | |
class main | |
capabilities SYS_ADMIN | |
# | |
# Set RLIMIT_MEMLOCK to 1GiB for bpfloader | |
# | |
# Actually only 8MiB would be needed if bpfloader ran as its own uid. | |
# | |
# However, while the rlimit is per-thread, the accounting is system wide. | |
# So, for example, if the graphics stack has already allocated 10MiB of | |
# memlock data before bpfloader even gets a chance to run, it would fail | |
# if its memlock rlimit is only 8MiB - since there would be none left for it. | |
# | |
# bpfloader succeeding is critical to system health, since a failure will | |
# cause netd crashloop and thus system server crashloop... and the only | |
# recovery is a full kernel reboot. | |
# | |
# We've had issues where devices would sometimes (rarely) boot into | |
# a crashloop because bpfloader would occasionally lose a boot time | |
# race against the graphics stack's boot time locked memory allocation. | |
# | |
# Thus bpfloader's memlock has to be 8MB higher then the locked memory | |
# consumption of the root uid anywhere else in the system... | |
# But we don't know what that is for all possible devices... | |
# | |
# Ideally, we'd simply grant bpfloader the IPC_LOCK capability and it | |
# would simply ignore it's memlock rlimit... but it turns that this | |
# capability is not even checked by the kernel's bpf system call. | |
# | |
# As such we simply use 1GiB as a reasonable approximation of infinity. | |
# | |
rlimit memlock 1073741824 1073741824 | |
oneshot |