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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 6 Mar 2014 13:08:10 -0800 (PST) From: David Rientjes <rientjes@...gle.com> To: Tejun Heo <tj@...nel.org> cc: Andrew Morton <akpm@...ux-foundation.org>, Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...e.cz>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, Christoph Lameter <cl@...ux-foundation.org>, Pekka Enberg <penberg@...nel.org>, Mel Gorman <mgorman@...e.de>, Oleg Nesterov <oleg@...hat.com>, Rik van Riel <riel@...hat.com>, Jianguo Wu <wujianguo@...wei.com>, Tim Hockin <thockin@...gle.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, cgroups@...r.kernel.org, linux-doc@...r.kernel.org Subject: Re: [patch 00/11] userspace out of memory handling On Thu, 6 Mar 2014, Tejun Heo wrote: > > This includes system oom handling alongside memcg oom handling. If you > > have specific objections, please let us know, thanks! > > Umm, that wasn't the bulk of objection, was it? We were discussion > the whole premise of userland oom handling and the conclusion, at > best, was that you couldn't show that it was actually necessary and > most other people disliked the idea. I'm not sure how you reach that conclusion: it's necessary because any process handling the oom condition will need memory to do anything useful. How else would a process that is handling a system oom condition, for example, be able to obtain a list of processes, check memory usage, issue a kill, do any logging, collect heap or smaps samples, or signal processes to throttle incoming requests without having access to memory itself? The system is oom. > Just changing a part of it and > resubmitting doesn't really change the whole situation. If you want > to continue the discussion on the basic approach, please do continue > that on the original thread so that we don't lose the context. I'm > gonna nack the respective patches so that they don't get picked up by > accident for now. > This is going to be discussed at the LSF/mm conference, I believe it would be helpful to have an actual complete patchset proposed so that it can be discussed properly. I feel no need to refer to an older patchset that would not apply and did not include all the support necessary for handling oom conditions. -- 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/
Powered by blists - more mailing lists