bpfloader - bump memlock rlimit to 1GiB

Test: build, atest
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5a1728fe29e510c06978a0c7c5cc90af3e9ea46d
This commit is contained in:
Maciej Żenczykowski 2020-01-27 22:27:02 -08:00
commit e1deaecda4

View file

@ -1,9 +1,33 @@
service bpfloader /system/bin/bpfloader
class main
capabilities SYS_ADMIN
# Set RLIMIT_MEMLOCK to 64MB for bpfloader
# Actually only 8MB is needed, but since bpfloader runs as root, it shares
# the global rlimit. Once bpfloader is running as its own user in the
# future, it will have dedicated rlimit to itself and this can be 8MB.
rlimit memlock 67108864 67108864
#
# 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