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
| ||
|
Date: Wed, 13 Apr 2016 15:45:20 +0200 From: Michal Hocko <mhocko@...nel.org> To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> Cc: akpm@...ux-foundation.org, oleg@...hat.com, rientjes@...gle.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] oom: consider multi-threaded tasks in task_will_free_mem On Wed 13-04-16 22:27:52, Tetsuo Handa wrote: > Michal Hocko wrote: > > > The whole thread group is going down does not mean we make sure that > > > we will send SIGKILL to other thread groups sharing the same memory which > > > is possibly holding mmap_sem for write, does it? > > > > And the patch description doesn't say anything about processes sharing > > mm. This is supposed to be a minor fix of an obviously suboptimal > > behavior of task_will_free_mem. Can we stick to the proposed patch, > > please? > > > > If we really do care about processes sharing mm _that_much_ then it > > should be handled in the separate patch. > > I do care. then feel free to post a patch. I believe such a change should be handled in a separate patch. I have intentionally layed out the code in a way to allow further checks easily. Separate processes sharing the same mm have lower priority for me because I do not know of any recent userspace which would use this strange threading model or do you have anything specific in mind which would make it more real-life? We will get to this eventually. > The OOM reaper cannot work unless SIGKILL is sent to a thread > which is holding mmap_sem for write. Thus, sending SIGKILL to all thread > groups sharing the mm is needed by your down_write_killable(&mm->mmap_sem) > changes. Like I wrote at > http://lkml.kernel.org/r/201604092300.BDI39040.FFSQLJOMHOOVtF@I-love.SAKURA.ne.jp , > we cannot fix that problem unless you accept the slowpath. > > I don't like you don't explain your approach for handling the slowpath. > If you explain your approach for handling the slowpath and I agree on > your approach, I will also agree on the proposed patches. I would much appreciate if you _stopped_ conflating different things together. This is just generating a lot of fuzz and slows the overal progress. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists