Re: [PATCH -v2] freezer: check OOM kill while being frozen

From: Michal Hocko
Date: Mon Oct 20 2014 - 11:17:33 EST


On Fri 17-10-14 18:10:21, Oleg Nesterov wrote:
> On 10/17, Michal Hocko wrote:
> >
> > I think we should rather get back to __thaw_task here.
>
> Yes, agreed.
>
> > Andrew could you replace the previous version by this one, please?
>
> Yes, that patch should be dropped...
>
>
> And can't resist... please look at
> http://marc.info/?l=linux-kernel&m=138427535430827 ;)
>
> > --- a/kernel/freezer.c
> > +++ b/kernel/freezer.c
> > @@ -45,13 +45,28 @@ bool freezing_slow_path(struct task_struct *p)
> > if (pm_nosig_freezing || cgroup_freezing(p))
> > return true;
> >
> > - if (pm_freezing && !(p->flags & PF_KTHREAD))
> > + if (!(p->flags & PF_KTHREAD))
>
> Why? Doesn't this mean that try_to_freeze() can race with thaw_processes()
> and then this task can be frozen for no reazon?

Hmm, this wasn't there in the v4 of the original patch from Cong.
http://marc.info/?l=linux-kernel&m=140986986423092. I cannot find any
reference to this hunk and it might be misapplied patch when I took the
patch from the list. I do not see any reason for this change.

> > +static bool should_thaw_current(bool check_kthr_stop)
> > +{
> > + if (!freezing(current))
> > + return true;
> > +
> > + if (check_kthr_stop && kthread_should_stop())
> > + return true;
> > +
> > + /* It might not be safe to check TIF_MEMDIE for pm freeze. */
> > + if (cgroup_freezing(current) && test_thread_flag(TIF_MEMDIE))
>
> I still think that the comment should tell more to explain why this
> is not safe.

I have suggested removing this check here:
http://marc.info/?l=linux-kernel&m=141078015130905 and it shouldn't be
really here. I must have screwed something up when rebasing the
series... Sorry about that!

Anyway the leader of the series should describe what was unsafe and how
it got fixed: http://marc.info/?l=linux-mm&m=141277728508500&w=2

> And if this is not safe, it is not clear how/why cgroup_freezing() can
> save us, both pm_freezing and CGROUP_FREEZING can be true?

You mean that the pm_freezer would race with cgroup one?

> And I think that this TIF_MEMDIE should go into freezing_slow_path(),
> so we do not even need should_thaw_current().

OK, it would make the patch simpler. On the other hand having the check
in the __refrigerator makes it easier to follow. freezing is called from
too many places. But I see your point, I guess. It really doesn't make
sense to go into fridge when it is clear that the task wouldn't get
frozen anyway. Some users even check the return value of freezing and do
different things in two paths. Those seem to be mostly kernel threads
but I haven't checked all the places. Anyway this should be irrelevant
to the OOM POV.

> This also looks more safe to me. Suppose that a task does
>
> while (try_to_freeze())
> ;
>
> Yes, this is pointless but correct. And in fact I think this pattern
> is possible. If this task is killed by OOM, it will spin forever.

I am really not sure what such a code would be supposed to do.

Anyway, updated patch is below. I have still kept Cong as the original
author but please let me know if this is not OK after considerable
changes in the patch.
Does it make more sense to you now, Oleg?
---