Joel Fernandes | 6e1341e | 2018-11-29 11:36:13 -0800 | [diff] [blame] | 1 | service bpfloader /system/bin/bpfloader |
| 2 | class main |
Maciej Żenczykowski | 3c057e6 | 2020-01-27 15:32:45 +0000 | [diff] [blame] | 3 | capabilities SYS_ADMIN |
Maciej Żenczykowski | e1deaec | 2020-01-27 22:27:02 -0800 | [diff] [blame^] | 4 | # |
| 5 | # Set RLIMIT_MEMLOCK to 1GiB for bpfloader |
| 6 | # |
| 7 | # Actually only 8MiB would be needed if bpfloader ran as its own uid. |
| 8 | # |
| 9 | # However, while the rlimit is per-thread, the accounting is system wide. |
| 10 | # So, for example, if the graphics stack has already allocated 10MiB of |
| 11 | # memlock data before bpfloader even gets a chance to run, it would fail |
| 12 | # if its memlock rlimit is only 8MiB - since there would be none left for it. |
| 13 | # |
| 14 | # bpfloader succeeding is critical to system health, since a failure will |
| 15 | # cause netd crashloop and thus system server crashloop... and the only |
| 16 | # recovery is a full kernel reboot. |
| 17 | # |
| 18 | # We've had issues where devices would sometimes (rarely) boot into |
| 19 | # a crashloop because bpfloader would occasionally lose a boot time |
| 20 | # race against the graphics stack's boot time locked memory allocation. |
| 21 | # |
| 22 | # Thus bpfloader's memlock has to be 8MB higher then the locked memory |
| 23 | # consumption of the root uid anywhere else in the system... |
| 24 | # But we don't know what that is for all possible devices... |
| 25 | # |
| 26 | # Ideally, we'd simply grant bpfloader the IPC_LOCK capability and it |
| 27 | # would simply ignore it's memlock rlimit... but it turns that this |
| 28 | # capability is not even checked by the kernel's bpf system call. |
| 29 | # |
| 30 | # As such we simply use 1GiB as a reasonable approximation of infinity. |
| 31 | # |
| 32 | rlimit memlock 1073741824 1073741824 |
Joel Fernandes | 6e1341e | 2018-11-29 11:36:13 -0800 | [diff] [blame] | 33 | oneshot |