linux-kernel - Re: [PATCH] copy over oom

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:	Fri, 24 Jul 2009 10:10:08 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	kosaki.motohiro@...fujitsu.com, Paul Menage <menage@...gle.com>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, mel@....ul.ie, npiggin@...e.de
Subject: Re: [PATCH] copy over oom_adj value at fork time

> On Fri, 24 Jul 2009, KOSAKI Motohiro wrote:
> 
> > > It's the API that's existed for years with no complaints, AFAICS.
> > 
> > I think thead and vfork() should be separeted on this discussion.
> > I agree vfork() regression should be fixed. but I don't think anyone
> > hope per-thread oom score. 
> > 
> > Of cource, if simple reverting is best way, I don't oppose this.... ;-)
> > 
> 
> Simply reverting it isn't an option unless you fix the underlying livelock 
> problem that my patches originally addressed and no viable alternative has 
> been proposed.

I disagree.
I agree with old behavior have one bug. but it doesn't provide any regression
allowing reason although old behavior is totally suck.

David, We already know your patch break real application. it is never acceptable.


> On the other hand, I think adding /proc/pid/oom_adj_child would solve the 
> userspace issue.  oom_adj_child would be the oom_adj value that is used by 
> the newly initialized mm_struct; this would allow the vfork'd child to 
> share the same oom_score with the parent and then be replaced with an 
> alternate score on execve().

Not solve. "please rewrite your application" isn't good solution.

Hm...
This is just idea, Does moving oom_adj from mm_struct to signal_struct solve
this problem?
I mean vfork() share mm_struct, but doesn't share signal_struct.




> 
> oom_adj_child would only be allowed to be greater (i.e. the more preferred 
> victim) than oom_adj for any given thread since the oom killer tries to 
> kill a child of the selected task first if it doesn't share memory.


--
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/