[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpXWeYtnT8_p4xJROom24u6G=i=0nkALx8tDfOhwA+zNqw@mail.gmail.com>
Date: Mon, 8 Sep 2014 16:00:41 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Tejun Heo <tj@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
David Rientjes <rientjes@...gle.com>,
Michal Hocko <mhocko@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Patch v4 1/2] freezer: check OOM kill while being frozen
On Mon, Sep 8, 2014 at 4:15 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
>> > Well, not exactly from anywhere. Just from where try_to_freeze() is called
>> > I suppose?
>>
>> Yeap, anywhere try_to_freeze() may be called.
>>
>> > Which means that if this is a user space task, it won't to a lot before dying,
>> > will it?
>>
>> Userland tasks aren't likely to a lot of damages before dying but then
>> again there's no guarantee. As it currently stands, try_to_freeze()
>> can be anywhere.
>
> Well, in that case the TIF_MEMDIE test alone is not sufficient in my opinion,
> because we can't guarantee that the task will not do something it was frozen
> to prevent it from doing.
>
>
That is true, there is a small window between TIF_MEMDIE is set
and SIGKILL is handled (aka process is killed), but this seems to
be a general signal handling issue not related with freezer after all
OOM relies on SIGKILL to function. No?
--
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/
Powered by blists - more mailing lists