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:
parent
3c057e6b7b
commit
e1deaecda4
1 changed files with 29 additions and 5 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue