On Tuesday, August 20, 2013 01:20:03 PM Bartlomiej Zolnierkiewicz wrote:
> Change __refrigerator() to allow SIGKILL signal handling during
> the frozen state (by setting task to a TASK_KILLABLE state instead
> of TASK_UNINTERRUPTIBLE one before entering sleep) and make tasks
> leave __refrigerator() upon receiving such signal.
>
> These changes allow frozen tasks to be killed immediately without
> the need to thaw them first.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> Signed-off-by: Kyungmin Park <[email protected]>
Well, it doesn't sound like an entirely bad idea to me, but I'd like to know
what Colin and Tejun (CCed now) think about it.
Thanks,
Rafael
> ---
> kernel/freezer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/freezer.c b/kernel/freezer.c
> index b462fa1..0c05a7a 100644
> --- a/kernel/freezer.c
> +++ b/kernel/freezer.c
> @@ -57,12 +57,13 @@ bool __refrigerator(bool check_kthr_stop)
> pr_debug("%s entered refrigerator\n", current->comm);
>
> for (;;) {
> - set_current_state(TASK_UNINTERRUPTIBLE);
> + set_current_state(TASK_KILLABLE);
>
> spin_lock_irq(&freezer_lock);
> current->flags |= PF_FROZEN;
> if (!freezing(current) ||
> - (check_kthr_stop && kthread_should_stop()))
> + (check_kthr_stop && kthread_should_stop()) ||
> + fatal_signal_pending(current))
> current->flags &= ~PF_FROZEN;
> spin_unlock_irq(&freezer_lock);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
Hello,
On Tue, Aug 20, 2013 at 02:23:32PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, August 20, 2013 01:20:03 PM Bartlomiej Zolnierkiewicz wrote:
> > Change __refrigerator() to allow SIGKILL signal handling during
> > the frozen state (by setting task to a TASK_KILLABLE state instead
> > of TASK_UNINTERRUPTIBLE one before entering sleep) and make tasks
> > leave __refrigerator() upon receiving such signal.
> >
> > These changes allow frozen tasks to be killed immediately without
> > the need to thaw them first.
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> > Signed-off-by: Kyungmin Park <[email protected]>
>
> Well, it doesn't sound like an entirely bad idea to me, but I'd like to know
> what Colin and Tejun (CCed now) think about it.
The problem is that we really don't know where each task is frozen in
the kernel so don't know what happens after the task leaves the
freezer is safe whether it's dying or not. We don't have any rules
restricting where a freeze point should be and a task may do any
operation between freezer and actual exit.
So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
TASK_KILLABLE at this point. We really need to strictly define where
a task can freeze before being able to do anything like this.
Thanks.
--
tejun
On Tuesday, August 20, 2013 08:18:19 AM Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 20, 2013 at 02:23:32PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, August 20, 2013 01:20:03 PM Bartlomiej Zolnierkiewicz wrote:
> > > Change __refrigerator() to allow SIGKILL signal handling during
> > > the frozen state (by setting task to a TASK_KILLABLE state instead
> > > of TASK_UNINTERRUPTIBLE one before entering sleep) and make tasks
> > > leave __refrigerator() upon receiving such signal.
> > >
> > > These changes allow frozen tasks to be killed immediately without
> > > the need to thaw them first.
> > >
> > > Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> > > Signed-off-by: Kyungmin Park <[email protected]>
> >
> > Well, it doesn't sound like an entirely bad idea to me, but I'd like to know
> > what Colin and Tejun (CCed now) think about it.
>
> The problem is that we really don't know where each task is frozen in
> the kernel so don't know what happens after the task leaves the
> freezer is safe whether it's dying or not. We don't have any rules
> restricting where a freeze point should be and a task may do any
> operation between freezer and actual exit.
>
> So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
> TASK_KILLABLE at this point. We really need to strictly define where
> a task can freeze before being able to do anything like this.
But we could do that for user space tasks I suppose?
Rafael
On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
> > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
> > TASK_KILLABLE at this point. We really need to strictly define where
> > a task can freeze before being able to do anything like this.
>
> But we could do that for user space tasks I suppose?
Even for userland tasks, we don't know where the task is stuck at. I
think there are enough freeze points in the kernel which are in the
middle of something which can be used by userland tasks excuting some
syscall. We need to collect all those sites into well defined trap
points before doing this.
Thanks.
--
tejun
On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote:
> On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
> > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
> > > TASK_KILLABLE at this point. We really need to strictly define where
> > > a task can freeze before being able to do anything like this.
> >
> > But we could do that for user space tasks I suppose?
>
> Even for userland tasks, we don't know where the task is stuck at. I
> think there are enough freeze points in the kernel which are in the
> middle of something which can be used by userland tasks excuting some
> syscall. We need to collect all those sites into well defined trap
> points before doing this.
OK, thanks!
On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote:
> > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
> > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
> > > > TASK_KILLABLE at this point. We really need to strictly define where
> > > > a task can freeze before being able to do anything like this.
> > >
> > > But we could do that for user space tasks I suppose?
> >
> > Even for userland tasks, we don't know where the task is stuck at. I
> > think there are enough freeze points in the kernel which are in the
> > middle of something which can be used by userland tasks excuting some
> > syscall. We need to collect all those sites into well defined trap
> > points before doing this.
>
> OK, thanks!
I scanned through try_to_freeze() users and it seems like we don't
have that many which can be hit by userland tasks. I think it should
be doable to audit all the users, remove the ones which can be invoked
by userland and make try_to_freeze() whine loudly if it's running off
a userland task except from well-defined spots. Anyways, we need to
ensure that userland task doesn't get stuck deep in the kernel before
allowing this.
Thanks.
--
tejun
On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote:
> On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote:
> > > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
> > > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
> > > > > TASK_KILLABLE at this point. We really need to strictly define where
> > > > > a task can freeze before being able to do anything like this.
> > > >
> > > > But we could do that for user space tasks I suppose?
> > >
> > > Even for userland tasks, we don't know where the task is stuck at. I
> > > think there are enough freeze points in the kernel which are in the
> > > middle of something which can be used by userland tasks excuting some
> > > syscall. We need to collect all those sites into well defined trap
> > > points before doing this.
> >
> > OK, thanks!
>
> I scanned through try_to_freeze() users and it seems like we don't
> have that many which can be hit by userland tasks. I think it should
> be doable to audit all the users, remove the ones which can be invoked
> by userland and make try_to_freeze() whine loudly if it's running off
> a userland task except from well-defined spots.
Which might be worth doing anyway to be sure we know what's going on.
> Anyways, we need to ensure that userland task doesn't get stuck deep in the
> kernel before allowing this.
Agreed.
Thanks,
Rafael
On Tue, Aug 20, 2013 at 9:41 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote:
>> On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote:
>> > On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote:
>> > > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
>> > > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
>> > > > > TASK_KILLABLE at this point. We really need to strictly define where
>> > > > > a task can freeze before being able to do anything like this.
>> > > >
>> > > > But we could do that for user space tasks I suppose?
>> > >
>> > > Even for userland tasks, we don't know where the task is stuck at. I
>> > > think there are enough freeze points in the kernel which are in the
>> > > middle of something which can be used by userland tasks excuting some
>> > > syscall. We need to collect all those sites into well defined trap
>> > > points before doing this.
>> >
>> > OK, thanks!
>>
>> I scanned through try_to_freeze() users and it seems like we don't
>> have that many which can be hit by userland tasks. I think it should
>> be doable to audit all the users, remove the ones which can be invoked
>> by userland and make try_to_freeze() whine loudly if it's running off
>> a userland task except from well-defined spots.
>
> Which might be worth doing anyway to be sure we know what's going on.
>
>> Anyways, we need to ensure that userland task doesn't get stuck deep in the
>> kernel before allowing this.
>
> Agreed.
Are there any update? we need this feature to kill frozen app easily.
Don't need to thaw app to kill.
Thank you,
Kyungmin Park
On Wednesday, September 25, 2013 02:52:26 PM Kyungmin Park wrote:
> On Tue, Aug 20, 2013 at 9:41 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote:
> >> On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote:
> >> > On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote:
> >> > > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
> >> > > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
> >> > > > > TASK_KILLABLE at this point. We really need to strictly define where
> >> > > > > a task can freeze before being able to do anything like this.
> >> > > >
> >> > > > But we could do that for user space tasks I suppose?
> >> > >
> >> > > Even for userland tasks, we don't know where the task is stuck at. I
> >> > > think there are enough freeze points in the kernel which are in the
> >> > > middle of something which can be used by userland tasks excuting some
> >> > > syscall. We need to collect all those sites into well defined trap
> >> > > points before doing this.
> >> >
> >> > OK, thanks!
> >>
> >> I scanned through try_to_freeze() users and it seems like we don't
> >> have that many which can be hit by userland tasks. I think it should
> >> be doable to audit all the users, remove the ones which can be invoked
> >> by userland and make try_to_freeze() whine loudly if it's running off
> >> a userland task except from well-defined spots.
> >
> > Which might be worth doing anyway to be sure we know what's going on.
> >
> >> Anyways, we need to ensure that userland task doesn't get stuck deep in the
> >> kernel before allowing this.
> >
> > Agreed.
>
> Are there any update? we need this feature to kill frozen app easily.
> Don't need to thaw app to kill.
No updates, but the above pretty much describes what needs to be done.
Thanks,
Rafael
On Wed, Sep 25, 2013 at 1:07 AM, Rafael J. Wysocki <[email protected]> wrote:
> On Wednesday, September 25, 2013 02:52:26 PM Kyungmin Park wrote:
>> On Tue, Aug 20, 2013 at 9:41 PM, Rafael J. Wysocki <[email protected]> wrote:
>> > On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote:
>> >> On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote:
>> >> > On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote:
>> >> > > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
>> >> > > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
>> >> > > > > TASK_KILLABLE at this point. We really need to strictly define where
>> >> > > > > a task can freeze before being able to do anything like this.
>> >> > > >
>> >> > > > But we could do that for user space tasks I suppose?
>> >> > >
>> >> > > Even for userland tasks, we don't know where the task is stuck at. I
>> >> > > think there are enough freeze points in the kernel which are in the
>> >> > > middle of something which can be used by userland tasks excuting some
>> >> > > syscall. We need to collect all those sites into well defined trap
>> >> > > points before doing this.
>> >> >
>> >> > OK, thanks!
>> >>
>> >> I scanned through try_to_freeze() users and it seems like we don't
>> >> have that many which can be hit by userland tasks. I think it should
>> >> be doable to audit all the users, remove the ones which can be invoked
>> >> by userland and make try_to_freeze() whine loudly if it's running off
>> >> a userland task except from well-defined spots.
>> >
>> > Which might be worth doing anyway to be sure we know what's going on.
>> >
>> >> Anyways, we need to ensure that userland task doesn't get stuck deep in the
>> >> kernel before allowing this.
>> >
>> > Agreed.
>>
>> Are there any update? we need this feature to kill frozen app easily.
>> Don't need to thaw app to kill.
>
> No updates, but the above pretty much describes what needs to be done.
FWIW, the places I added try_to_freeze (which are all accessible from
userspace tasks) were all audited to make sure they weren't holding
any shared resources. I didn't check if they would leak any memory if
the process was killed there, but they aren't holding any locks. It's
pretty easy to audit them, just follow the error paths up each
function - if the first error path after the freezing function doesn't
free any resources then that function is safe, and repeat for each
function that calls it.
On the other hand, would it be better to send a kill to the process
and thaw it, and let it exit before returning to userspace?