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
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:23:57 -0800 (PST)
From:	David Rientjes <>
To:	Tejun Heo <>
cc:	Andrew Morton <>,
	Johannes Weiner <>,
	Michal Hocko <>,
	KAMEZAWA Hiroyuki <>,
	Christoph Lameter <>,
	Pekka Enberg <>,
	Mel Gorman <>, Oleg Nesterov <>,
	Rik van Riel <>,
	Jianguo Wu <>,
	Tim Hockin <>,,,,
Subject: Re: [patch 00/11] userspace out of memory handling

On Thu, 6 Mar 2014, Tejun Heo wrote:

> > 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.
> We're now just re-starting the whole discussion with all context lost.
> How is this a good idea?  We talked about all this previously.  If you
> have something to add, add there *please* so that other people can
> track it too.

I'm referring to system oom handling as an example above, in case you 
missed my earlier email a few minutes ago: the previous patchset did not 
include support for system oom handling.  Nothing that I wrote above was 
possible with the first patchset.  This is the complete support.

> That's completely fine but if that's your intention please at least
> prefix the patchset with RFC and explicitly state that no consensus
> has been reached (well, it was more like negative consensus from what
> I remember) in the description so that it can't be picked up
> accidentally.

This patchset provides a solution to a real-world problem that is not 
solved with any other patchset.  I expect it to be reviewed as any other 
patchset, it's not an "RFC" from my perspective: it's a proposal for 
inclusion.  Don't worry, Andrew is not going to apply anything 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists