Re: [patch 05/18] oom: give current access to memory reserves if it has been killed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > +	/*
> > > +	 * If current has a pending SIGKILL, then automatically select it.  The
> > > +	 * goal is to allow it to allocate so that it may quickly exit and free
> > > +	 * its memory.
> > > +	 */
> > > +	if (fatal_signal_pending(current)) {
> > > +		set_thread_flag(TIF_MEMDIE);
> > > +		return;
> > > +	}
> > > +
> > >  	if (sysctl_panic_on_oom == 2) {
> > >  		dump_header(NULL, gfp_mask, order, NULL);
> > >  		panic("out of memory. Compulsory panic_on_oom is selected.\n");
> > 
> > Sorry, I had found this patch works incorrect. I don't pulled.
> > 
> 
> You're taking back your ack?
> 
> Why does this not work?  It's not killing a potentially immune task, the 
> task is already dying.  We're simply giving it access to memory reserves 
> so that it may quickly exit and die.  OOM_DISABLE does not imply that a 
> task cannot exit on its own or be killed by another application or user, 
> we simply don't want to needlessly kill another task when current is dying 
> in the first place without being able to allocate memory.
> 
> Please reconsider your thought.

Oh, I didn't talk about OOM_DISABLE. probably my explanation was too
poor.

My point is, the above code assume SIGKILL is good sign of the task is
going exit soon. but It is not always true. Only if the task is regular
userland process, it's true. kernel module author freely makes very strange
kernel thread.

note: Linux is one of most popular generic purpose OS in the world and
we have million out of funny drivers.

Plus, If false positive occur, setting TIF_MEMDIE is very dangerous because
if there is TIF_MEMDIE task, our kernl don't send next OOM-Kill. It mean
the systam can reach dead lock. In the other hand, false negative is relatively
safe. It cause one innocent task kill. but the system doesn't cause lockup.

Then, we have strongly motivation to avoid false positive. I hope you add 
some conservative check.

I don't disagree your patch concept. I only worry about the dangerousness.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]