diff options
| author | Li Li <dualli@google.com> | 2021-07-01 15:10:05 -0700 |
|---|---|---|
| committer | Suren Baghdasaryan <surenb@google.com> | 2021-07-02 02:03:20 +0000 |
| commit | cc25244b774a7063c0a212b883b251e47573af1c (patch) | |
| tree | 139664646c21c3639d08204d47e0fd89b87e35c7 /trusty/coverage/coverage_test.cpp | |
| parent | a21c4c1a80db92398c886f96cbed0a9554d23c6b (diff) | |
libprocessgroup: Do not remove uid cgroups directory
In some rare cases, race happens between 2 processes in the same uid.
1. Process A is dying
2. system_server calls RemoveProcessGroup() for A
3. Zygote forks Process B with the same uid of A
4. system_server calls MkdirAndChown(uid) for B
5. system_server calls MkdirAndChown(uid, pid) for B
As 2 & 4/5 belong to different threads, 2 might happens before or after
step 4/5, or even in the middle of 4/5. In such a case, 4 or 5 will
fail, leaving process B in wrong (Zygote) group.
The uid dir is only created when the corresponding apps have been
launched at least once. It's reasonable to assume one of them is going
to be launched again. Deleting and recreating the uid dir just slows
down applaunch.
Introducing a new lock in libprocessgroup can also solve the race issue.
But that will slow down the applaunch further.
Therefore, reusing the uid dir is an optimized way to solve the race.
Ignore-AOSP-First: Freezer is not a public feature yet
Bug: 192512069
Bug: 168907513
Test: Kill corresponding apps and check the uid cgroupfs dir
Change-Id: I2e91088f21f45e4eda6c709a4af65ace7e135801
Diffstat (limited to 'trusty/coverage/coverage_test.cpp')
0 files changed, 0 insertions, 0 deletions