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: <20090630090936.GC1114@wotan.suse.de>
Date:	Tue, 30 Jun 2009 11:09:36 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	David Rientjes <rientjes@...gle.com>
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, Jun 30, 2009 at 01:41:12AM -0700, David Rientjes wrote:
> 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.

I don't see the importance of calling the oom killer. If a thread
is TIF_MEMDIE, then we should not try to enter reclaim nor try to
call the oom killer. The oom killer has already been activated and
because it has been determined that nothing can be reclaimed...

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

I don't mean the normal oom-killer path, but another call to say
"this thread got stuck, un-kill me and look for someone else to kill"
or somesuch.

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

Why only order-0? What would you do at 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/