linux-kernel - Re: [PATCH] oom: create a resource limit for 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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 11 Nov 2010 12:57:35 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Mandeep Singh Baines <msb@...omium.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>,
	Ying Han <yinghan@...gle.com>, linux-kernel@...r.kernel.org,
	gspencer@...omium.org, piman@...omium.org, wad@...omium.org,
	olofj@...omium.org
Subject: Re: [PATCH] oom: create a resource limit for oom_adj

On Thu, 11 Nov 2010, Mandeep Singh Baines wrote:

> > What is the anticipated use case for this?  We know that you want to lower 
> > oom_adj without CAP_SYS_RESOURCE, but what's the expected behavior when an 
> > app moves from foreground to background?  I assume it's something like 
> 
> The focus here is the web browser's tabs. In our case, each is a process. If
> OOM is going to kill a process, you'd rather it kill the tab you looked at
> hours ago instead of the one you're looking at now. So you'd like to have a
> policy where the LRU tab gets killed first. We'd like to use oom_score_adj
> as the mechanism to implement an LRU policy like this.
> 

Hmm, at first glance that seems potentially dangerous if the current tab 
generates a burt of memory allocations and it ends up killing all other 
tabs before finally targeting the culprit whereas currently the heuristic 
should do a good job of finding this problematic tab and killing it 
instantly.

Perhaps that can't happen and it probably doesn't even matter: 
oom_score_adj allows users to determine which process to kill regardless 
of the underlying reason.

> > What do you anticipate will be writing to oom_score_adj with this patch, 
> > the app itself?
> 
> A process in the browser session will do the adusting. We'd rather not give
> it CAP_SYS_RESOURCE. It should only be allowed to change oom_score_adj up
> and down within the bounds set by the administrator. Analagous to renice()
> which we also do using a similar policy.
> 

So as more and more tabs get used, the least recently used tab gets its 
oom_score_adj raised higher and higher until it is reused itself and then 
it gets reset back to 0 for the current tab?

Is there a reason you don't want to give the underlying browser session 
process CAP_SYS_RESOURCE?  Will it not be enforcing resource limits to 
ensure tabs don't deplete all memory when certain sites are opened?  Are 
you concerned that it may deplete all memory itself (for which case you 
could raise its own oom_score_adj, which is a proportion of available 
memory so you can define where that point of depletiong is)?
--
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/