linux-kernel - Re: upcoming kerneloops.org item: get_page_from

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]

Message-ID: <alpine.DEB.2.00.0906300128510.16291@chino.kir.corp.google.com>
Date:	Tue, 30 Jun 2009 01:41:12 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Nick Piggin <npiggin@...e.de>
cc:	Mel Gorman <mel@....ul.ie>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	penberg@...helsinki.fi, arjan@...radead.org,
	linux-kernel@...r.kernel.org, cl@...ux-foundation.org
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist

On Tue, 30 Jun 2009, Nick Piggin wrote:

> > I'd agree with Mel's added check for TIF_MEMDIE upon returning from the 
> > oom killer, but only for __GFP_NOMEMALLOC.
> 
> NOMEMALLOC indeed should always be kept away from memalloc/memdie
> reserves. That's how it should have worked when I added it (but
> I may have forgotten TIF_MEMDIE, I can't remember).
> 

Yeah, so if test_thread_flag(TIF_MEMDIE) and __GFP_NOMEMALLOC, then it 
makes sense to return NULL immediately following the call to the oom 
killer for !__GFP_NOFAIL since retrying the allocation is pointless 
(reclaim failed already and TIF_MEMDIE doesn't help us on the next 
attempt) at that time.

> > The oom killer currently is a no-op if any eligible task has TIF_MEMDIE, 
> > so this would require adding an oom killer timeout so that if a task fails 
> > to exit after a predefined period, TIF_MEMDIE is cleared and the task is 
> > marked to no longer be selected (which would require an addition to 
> > task_struct) although it may have already completely depleted memory 
> > reserves.
> 
> It wouldn't have to be a timeout, it could be a call back to the
> oom killer.
> 

Calling the oom killer won't do anything since it will not kill another 
task while another has TIF_MEMDIE to protect those memory reserves and 
give the oom killed task a chance to exit.

Panicking when a thread with TIF_MEMDIE set cannot find any memory and the 
allocation is __GFP_NOFAIL makes sense, but only for order 0.
--
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/