From: San Mehat Date: Mon, 26 Apr 2010 22:11:04 +0000 (-0700) Subject: staging: android: lowmemorykiller: Don't try to kill the same pid over and over X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=4964cd41cd966502c1e0c5bc929ed15c175f8218;p=GitHub%2Fexynos8895%2Fandroid_kernel_samsung_universal8895.git staging: android: lowmemorykiller: Don't try to kill the same pid over and over Under certain circumstances, a process can take awhile to handle a sig-kill (especially if it's in a scheduler group with a very low share ratio). When this occurs, lowmemkiller returns to vmscan indicating the process memory has been freed - even though the process is still waiting to die. Since the memory hasn't actually freed, lowmemkiller is called again shortly after, and picks the same process to die; regardless of the fact that it has already been 'scheduled' to die and the memory has already been reported to vmscan as having been freed. Solution is to check fatal_signal_pending() on the selected task, and if it's already pending destruction return; indicating to vmscan that no resources were freed on this pass. Signed-off-by: San Mehat Signed-off-by: Greg Kroah-Hartman --- diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index 32314e85e2b7..83721786dead 100644 --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -133,6 +133,12 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask) p->pid, p->comm, oom_adj, tasksize); } if (selected) { + if (fatal_signal_pending(selected)) { + pr_warning("process %d is suffering a slow death\n", + selected->pid); + read_unlock(&tasklist_lock); + return rem; + } lowmem_print(1, "send sigkill to %d (%s), adj %d, size %d\n", selected->pid, selected->comm, selected_oom_adj, selected_tasksize);