linux-kernel - Re: [PATCH] Fix the issue that lowmemkiller fell into a cycle that try to kill a task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Sep 2014 11:34:12 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Hui Zhu <zhuhui@...omi.com>, gregkh@...uxfoundation.org,
	rientjes@...gle.com, vinayakm.list@...il.com,
	weijie.yang@...sung.com
CC:	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	teawater@...il.com
Subject: Re: [PATCH] Fix the issue that lowmemkiller fell into a cycle that
 try to kill a task

On 09/22/2014 10:57 PM, Hui Zhu wrote:
> The cause of this issue is when free memroy size is low and a lot of task is
> trying to shrink the memory, the task that is killed by lowmemkiller cannot get
> CPU to exit itself.
> 
> Fix this issue with change the scheduling policy to SCHED_FIFO if a task's flag
> is TIF_MEMDIE in lowmemkiller.

Is it actually true that the task that was killed by lowmemkiller
cannot get CPU time?

It is also possible that the task is busy in the kernel, for example
in the reclaim code, and is not breaking out of some loop fast enough,
despite the TIF_MEMDIE flag being set.

I suspect SCHED_FIFO simply papers over that kind of issue, by not
letting anything else run until the task is gone, instead of fixing
the root cause of the problem.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/