Re: [PATCH] mm,oom: use per signal_struct flag rather than clear TIF_MEMDIE

[Michal Hocko <mhocko@kernel.org>]

On Wed 29-06-16 22:24:24, Oleg Nesterov wrote:
> On 06/28, Michal Hocko wrote:
> >
> > On Mon 27-06-16 22:40:17, Oleg Nesterov wrote:
> > >
> > > Ah, but this is clear, note the "Ignoring the obvious races" above.
> > > Can't we fix this race? I am a bit lost, but iirc we want this anyway
> > > to ensure that we do not set TIF_MEMDIE if ->mm == NULL ?
> >
> > This is not about a race it is about not reaching exit_oom_victim and
> > unblock the oom killer from selecting another victim.
> 
> I understand. What I do not understand why we can't rely on MMF_OOM_REAPED
> if we ensure that TIF_MEMDIE can only be set if the victim did not call
> exit_oom_victim() yet.
> 
> OK, please forget, I already got lost and right now I don't even have the
> uptodate -mm tree sources.
> 
> > > Hmm. Although I am not sure I really understand the "may block for
> > > unbounded period ..." above. Do you mean khugepaged_exit?
> >
> > __mmput->exit_aio can wait for IO to complete and who knows what that
> > might depend on.
> 
> Yes, but I was confused by "waiting for somebody else's memory allocation",
> I do not this this apllies to exit_aio.

To be honest I really don't know. I am just assuming the worst. And IO
sometimes need to allocate to move on.

> Nevermind,
> 
> > Who knows how many others are lurking there.
> 
> Yes, yes, I agree. Just I wrongly thought Tetsuo meant something particular.

I guess we just want to be conservative here and make sure we do not
want to depend on the particular implementation details.
-- 
Michal Hocko
SUSE Labs

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