Prevent that the statement that writes '\0' past the read data can write
past the end of the buffer.
Bug: 213617178
Test: Compile-tested only.
Change-Id: I6922c343a6bcb52dce0b5cf54f09b2850e9dfde2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Using ARRAY_SIZE() on a pointer yields 1 while applying .size() to a
pointer triggers a compiler error. Hence use .size() instead of
ARRAY_SIZE().
Bug: 213617178
Test: Compile-tested only.
Change-Id: Ie0f9740f59470c943f8d62b9475f7f987ed8707b
Signed-off-by: Bart Van Assche <bvanassche@google.com>
std::min() and std::max() check whether the argument types match but
min() and max() not. Hence switch to std::min() and std::max().
Bug: 213617178
Test: Compile-tested only.
Change-Id: Iaf1f63360c9360938db56d485dbd1e504129c52d
Signed-off-by: Bart Van Assche <bvanassche@google.com>
When system is under heavy memory pressure the system might be able
to keep free memory above the min watermark avoiding perceptible app
kills. In such situation system might end up using all its cpu
capacity on memory reclaim and not doing productive work. To detect
this condition, check memory full stall and compare it with the new
ro.lmk.stall_limit_critical tunable representing the stall threshold.
When the recorded level is over ro.lmk.stall_limit_critical, lmkd will
be allowed to kill perceptible apps. ro.lmk.stall_limit_critical
represents the max memory full stall in % that is allowed before
perceptible apps will get killed. By default it is set to 100%, which
effectively disables the feature.
Currently system stall is measured based on psi memory stall 10s average
value, however this definition might change in the future if better
metrics are developed. Setting ro.lmk.stall_limit_critical to 5 means
the system should be fully stalled (no productive work is done) for 5%
of the 10sec period, resulting in 0.5 sec loss due to the stall.
Bug: 205182133
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9713e30d82641d86d1b7edb5e1ba2971b935c898
Increase the allocation step to 5MB and decrease the delay between
allocations to 200ms in order to speed up memory consumption and
avoid the test timing out.
Bug: 217478668
Test: atest lmkd_tests:lmkd_tests.LmkdTest#TargetReaping -- --abi x86_64
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ia36229b280d79acd9d93a5ca1961d6cf1ef223df
Since lmkd tests require time to build up memory pressure, they cause
timeouts when run as part of presubmits. Move them into the
presubmit-large category with higher timeout to prevent such failures.
Bug: 217478668
Bug: 203597692
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I690133c9f849da58b85884a7d7b463f5b518c12f
Add a test to verify a process killed by lmkd is being reaped when
kernel supports process_mrelease syscall.
Bug: 203597692
Test: atest LmkdTest
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Iac46f68c811e6e89378952ce1d29daf8a47514e2
set_process_group_and_prio sets task profiles for each thread in the
process separately. This can be avoided by setting task profiles to
the entire process using its pid.
Bug: 215557553
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9c1917172019a42809385f6c9c084b8cb343b520
To detect lmkd being stuck on a syscall for prolonged period of time,
introduce a watchdog thread which gets set when lmkd starts handling of
events and is reset after handling is done. If it takes more than the
timeout period (2 sec) to handle an event, watchdog wakes up and kills
the least important process to prevent mounting memory pressure caused
by lmkd lockup. After a kill, watchdog will wait for the reset for
another timeout period and kill again. This repeats until lmkd unlocks
and resets the watchdog.
Bug: 201671997
Test: induce random sleep in lmkd main handler and observe watchdog kills
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I56a55834582e11c06cc6cf9da3bc7380e634b301
process_mrelease syscall can be used to expedite memory release of
a process after it was killed. This allows memory to be released
without the target process being scheduled, therefore does not depend
on target's priority or the CPU it's running on.
However process_mrelease syscall can take considerable time. Blocking
lmkd main thread during that time can cause memory pressure events
being missed while lmkd is busy reaping previous target's memory.
For this reason reaping should be done in a separate thread. This way
lmkd main thread can keep monitoring memory pressure while memory is
being released.
Introduce Reaper class which maintains a pool of threads to perform
process killing and reaping. The main thread submits a request to the
Reaper to kill and reap the process without blocking. If all the threads
in the pool are busy at the time the next kill is needed, the kill is
performed by the main thread without reaping.
Bug: 130172058
Bug: 189803002
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: If7b10fdd1838bdfeea3fed3031565feffe0b52be
lmkd daemon launches before system_server. If lowmem_targets_size
does not initialize by system_server, the value will be zero.
Before system_server starts lmkd receives a psi event
and debug_process_killing on, the lmkd crashes here.
Bug: 209090314
Signed-off-by: liuhailong <liuhailong@oppo.com>
Change-Id: I0736a882ed1ff5eee2b07676ae590a2cb2a7721c
Bart Van Assche
Suren Baghdasaryan
Xin Li
Yi Kong
liuhailong