linux-kernel - Re: [patch 00/11] userspace out of memory handling

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: Windows password security audit tool. GUI, reports in PDF.

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

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/