From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Gautham R Shenoy <ego@in.ibm.com>,
LKML <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH 1/7] Freezer: Read PF_BORROWED_MM in a nonracy way
Date: Sat, 12 May 2007 18:35:20 +0200 [thread overview]
Message-ID: <200705121835.21333.rjw@sisk.pl> (raw)
In-Reply-To: <20070512141813.GA98@tv-sign.ru>
On Saturday, 12 May 2007 16:18, Oleg Nesterov wrote:
> On 05/12, Rafael J. Wysocki wrote:
> >
> > ... user space tasks that call deamonize() can also be frozen prematurely.
> > We didn't take this possibility into consideration before, which was obviously
> > wrong.
>
> No, no, sorry for the confusion. User space tasks never call deamonize().
>
> Kernel threads call daemonize, because when we are doing kernel_thread()
> on behalf of user-space task, the new kernel thread (child) shares its
> ->mm with the caller (parent). So it is considered as "is_user_space()"
> until it does daemonize().
Ah, I see. We spawn a kernel thread from a code path that belongs to a
user space task and we need to call deamonize() to make it become a
'real' kernel thread.
Still, this means that is_user_space() may return 'true' for this thread
before it calls daemonize() and then the scenario described by me in the
previous message may occur. It seems.
> Definitely, is_user_space() should have another name.
Well, I have no (better) idea ...
> When a user space task exits, it does exit_mm() and becomes "a kernel thread"
> from the freezer POV. In its current from, freezer can do nothing with this.
> The exiting task won't call try_to_freeze() after that, so try_to_freeze_tasks()
> will wait until it dissapears (actually, until it calls exit_notify(), note
> the ->exit_state check in freezeable()).
>
> I do not think we can improve things if exit_mm() clears TIF_FREEZING.
I think we can avoid the above scenario (in which a kernel thread that has
called daemonize() "too late" ends up with TIF_FREEZE set and goes to
refrigerator() while we're freezing the user space).
> We should clear TIF_FREEZING when we set PF_NOFREEZE, I think. This was
> discussed before iirc, but I forgot the result.
It's in freezer-fix-pf_nofreeze-vs-freezeable-race.patch (appended for
convenience, white space may be broken).
Greetings,
Rafael
---
--- a/include/linux/freezer.h~freezer-fix-pf_nofreeze-vs-freezeable-race
+++ a/include/linux/freezer.h
@@ -63,8 +63,10 @@ static inline int thaw_process(struct ta
*/
static inline void frozen_process(struct task_struct *p)
{
- p->flags |= PF_FROZEN;
- wmb();
+ if (!unlikely(p->flags & PF_NOFREEZE)) {
+ p->flags |= PF_FROZEN;
+ wmb();
+ }
clear_tsk_thread_flag(p, TIF_FREEZE);
}
next prev parent reply other threads:[~2007-05-12 16:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-10 22:35 [PATCH 0/7] Freezer bugfixes Rafael J. Wysocki
2007-05-10 22:36 ` [PATCH 1/7] Freezer: Read PF_BORROWED_MM in a nonracy way Rafael J. Wysocki
2007-05-11 19:39 ` Andrew Morton
2007-05-11 20:21 ` Oleg Nesterov
2007-05-11 20:40 ` Rafael J. Wysocki
2007-05-11 22:56 ` Linus Torvalds
2007-05-11 23:20 ` Oleg Nesterov
2007-05-11 23:32 ` Linus Torvalds
2007-05-11 23:48 ` Oleg Nesterov
2007-05-12 0:05 ` Oleg Nesterov
2007-05-12 0:08 ` Linus Torvalds
2007-05-12 0:40 ` Oleg Nesterov
2007-05-12 1:01 ` Oleg Nesterov
2007-05-12 1:24 ` Linus Torvalds
2007-05-12 9:01 ` Rafael J. Wysocki
2007-05-12 10:45 ` Rafael J. Wysocki
2007-05-12 14:18 ` Oleg Nesterov
2007-05-12 16:35 ` Rafael J. Wysocki [this message]
2007-05-12 16:58 ` Oleg Nesterov
2007-05-12 17:16 ` Rafael J. Wysocki
2007-05-12 17:43 ` Oleg Nesterov
2007-05-12 1:11 ` Rafael J. Wysocki
2007-05-11 23:22 ` Rafael J. Wysocki
2007-05-11 23:25 ` Andrew Morton
2007-05-12 0:16 ` Rafael J. Wysocki
2007-05-11 23:29 ` Linus Torvalds
2007-05-12 0:01 ` Rafael J. Wysocki
2007-05-12 8:16 ` Gautham R Shenoy
2007-05-12 9:27 ` Rafael J. Wysocki
2007-05-12 10:13 ` Gautham R Shenoy
2007-05-12 10:41 ` Rafael J. Wysocki
2007-05-12 10:52 ` Gautham R Shenoy
2007-05-12 11:34 ` Rafael J. Wysocki
2007-05-12 14:25 ` Oleg Nesterov
2007-05-12 14:59 ` migrate_dead_tasks() vs sleep-after-exit_notify() problems? Oleg Nesterov
2007-05-10 22:37 ` [PATCH 2/7] Freezer: Close potential race between refrigerator and thaw_tasks Rafael J. Wysocki
2007-05-10 22:38 ` [PATCH 3/7] Freezer: Fix vfork problem Rafael J. Wysocki
2007-05-10 22:39 ` [PATCH 4/7] Freezer: Take kernel_execve into consideration Rafael J. Wysocki
2007-05-10 22:41 ` [PATCH 5/7] Freezer: Fix kthread_create vs freezer theoretical race Rafael J. Wysocki
2007-05-10 22:43 ` [PATCH 6/7] Freezer: Fix PF_NOFREEZE vs freezeable race Rafael J. Wysocki
2007-05-10 22:44 ` [PATCH 7/7] Freezer: Move frozen_process to kernel/power/process.c Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200705121835.21333.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=pavel@ucw.cz \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.