From: Gautham R Shenoy <ego@in.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@tv-sign.ru>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org, mingo@elte.hu, vatsa@in.ibm.com,
paulmck@us.ibm.com, pavel@ucw.cz
Subject: Re: [RFC PATCH(experimental) 2/2] Fix freezer-kthread_stop race
Date: Fri, 20 Apr 2007 16:16:47 +0530 [thread overview]
Message-ID: <20070420104647.GA11290@in.ibm.com> (raw)
In-Reply-To: <20070419143133.a6c82ef8.akpm@linux-foundation.org>
On Thu, Apr 19, 2007 at 02:31:33PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 17:34:19 +0530
> Gautham R Shenoy <ego@in.ibm.com> wrote:
>
>
> flush_workqueue() just needs to die. I think there are (almost) no
> legitimate users of it once cancel_work_sync() is merged.
>
> > This patch attempts to address such a situation with a fix for kthread_stop.
>
> Via wholly undescribed means :(
Sorry. I will document stuff better next time.
>
> > Strictly experimental. Compile tested on i386.
>
> Rather than doing <whatever you did>, perhaps we could make the freezing
> process a dual-pass thing. On pass 1, mark all the threads as "we'll be
> freezing you soon" and on the second pass, do the actual freezing. Then,
> in problematic places such as kthread_stop() we can look to see if we'll
> soon be asked to freeze and if so, run try_to_freeze().
We can do that. Just that the freezer will now have to wait for 2 sets
of ack's instead of 1 set before declaring the system as frozen.
But the whole point of the patch was so that a thread A can tell
a thread B that it's dependent on the latter, and hence would like
to postpone B's freezing for some time. So I am thinking if we can
achieve this through the scheme you described.
>
> Of course, running try_to_freeze() in kthread_stop() would be very wrong,
> so we'd actually need to do it in callers, preferably via a new
> kthread_stop_freezeable() wrapper.
>
Well, even then we'll need to ensure that a thread would not call
kthread_stop_freezeable() with any locks held. That would mean more
audits :)
> And the two-pass-freeze thing is of course racy. It's also unnecessary:
> setting a flag on every task in the machine is equivalent to setting a
> global variable. So perhaps just use a global variable?
>
> int kthread_stop_freezeable(struct task_struct *k)
> {
> if (freeze_state == ABOUT_TO_START) {
> wait_for(freeze_state == STARTED);
> try_to_freeze();
> }
> kthread_stop(k);
> }
>
> which is theoretically racy if another freeze_processes() starts
> immediately. Anyway - please have a think about it ;)
>
Sure, am already thinking about it :)
> > +static struct freezer_status_struct freezer_status = {
> > + .lock = SPIN_LOCK_UNLOCKED,
> > + .count = 0,
> > + };
>
> SPIN_LOCK_UNLOCKED is deprecated (it subverts lockdep)
>
Ok, will change it to __SPIN_LOCK_UNLOCKED(freezer_status.lock)
> > static inline int freezeable(struct task_struct * p)
> > {
> > if ((p == current) ||
> > @@ -45,7 +55,8 @@ void refrigerator(void)
> > * *after* the freezer did the freezeable() check
> > * on us.
> > */
> > - if (current->flags & PF_NOFREEZE) {
> > + if ((current->flags & PF_NOFREEZE) ||
> > + test_tsk_thread_flag(current, TIF_FREEZER_HELD)) {
> > clear_tsk_thread_flag(current, TIF_FREEZE);
> > task_unlock(current);
> > return;
> > @@ -63,12 +74,16 @@ void refrigerator(void)
> > recalc_sigpending(); /* We sent fake signal, clean it up */
> > spin_unlock_irq(¤t->sighand->siglock);
> >
> > + task_lock(current);
> > for (;;) {
> > set_current_state(TASK_UNINTERRUPTIBLE);
> > if (!frozen(current))
> > break;
> > + task_unlock(current);
> > schedule();
> > + task_lock(current);
> > }
> > + task_unlock(current);
> > pr_debug("%s left refrigerator\n", current->comm);
> > current->state = save;
>
> I guess we should use set_current_state() here.
>
> > +
> > + if (thaw_user_space) {
> > + spin_lock(&freezer_status.lock);
> > + if (freezer_status.count < 0)
> > + freezer_status.count++;
> > + spin_unlock(&freezer_status.lock);
> > + }
> > }
>
> whitespace went wrong
>
Huh! yeah, dunno how though.
> > +#define TIF_FREEZER_HELD 21 /* is temporarily holding up the
> > + * process freezer
> > + */
> >
> > #define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
> > #define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
> > @@ -102,6 +105,7 @@ struct thread_info {
> > #define _TIF_MCA_INIT (1 << TIF_MCA_INIT)
> > #define _TIF_DB_DISABLED (1 << TIF_DB_DISABLED)
> > #define _TIF_FREEZE (1 << TIF_FREEZE)
> > +#define _TIF_FREEZER_HELD (1 << TIF_FREEZER_HELD)
> >
> > /* "work to do on user-return" bits */
> > #define TIF_ALLWORK_MASK (_TIF_NOTIFY_RESUME|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT)
> > Index: linux-2.6.21-rc6/include/asm-mips/thread_info.h
> > ===================================================================
> > --- linux-2.6.21-rc6.orig/include/asm-mips/thread_info.h
> > +++ linux-2.6.21-rc6/include/asm-mips/thread_info.h
> > @@ -120,6 +120,7 @@ register struct thread_info *__current_t
> > #define TIF_MEMDIE 18
> > #define TIF_FREEZE 19
> > #define TIF_ALLOW_FP_IN_KERNEL 20
> > +#define TIF_FREEZER_HELD 21
> > #define TIF_SYSCALL_TRACE 31 /* syscall trace active */
> >
> > #define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
> > @@ -132,6 +133,7 @@ register struct thread_info *__current_t
> > #define _TIF_USEDFPU (1<<TIF_USEDFPU)
> > #define _TIF_POLLING_NRFLAG (1<<TIF_POLLING_NRFLAG)
> > #define _TIF_FREEZE (1<<TIF_FREEZE)
> > +#define _TIF_FREEZER_HELD (1<<TIF_FREEZER_HELD)
>
> hm, all this duplication is unpleasing. We could do something similar to
> include/linux/buffer_head.h:BH_PrivateStart here: get all architectures to
> define a TIF_COMMON_STUFF_STARTS_HERE then include asm-generic/whatever.h
> which defines all the flags which every architecture must define, as
> TIF_COMMON_STUFF_STARTS_HERE+0, TIF_COMMON_STUFF_STARTS_HERE+1, etc.
>
Ok.
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
next prev parent reply other threads:[~2007-04-20 10:46 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-19 12:01 [RFC 0/2] Fix Freezer related races Gautham R Shenoy
2007-04-19 12:02 ` [RFC PATCH 1/2] Fix PF_NOFREEZE and freezeable race Gautham R Shenoy
2007-04-19 21:39 ` Rafael J. Wysocki
2007-04-20 18:02 ` Oleg Nesterov
2007-04-23 10:26 ` Gautham R Shenoy
2007-04-23 17:49 ` Oleg Nesterov
[not found] ` <200704260044.03975.rjw@sisk.pl>
[not found] ` <20070425231638.GH15134@in.ibm.com>
[not found] ` <20070425163409.4f8476c4.akpm@linux-foundation.org>
[not found] ` <20070426060608.GA12892@in.ibm.com>
[not found] ` <20070425231232.302a83f0.akpm@linux-foundation.org>
2007-04-26 13:11 ` [PATCH -mm] Move frozen_process() to kernel/power/process.c Gautham R Shenoy
2007-04-26 12:36 ` Oleg Nesterov
2007-04-26 13:40 ` Gautham R Shenoy
2007-04-19 12:04 ` [RFC PATCH(experimental) 2/2] Fix freezer-kthread_stop race Gautham R Shenoy
2007-04-19 21:31 ` Andrew Morton
2007-04-20 8:54 ` Rafael J. Wysocki
2007-04-20 11:05 ` Gautham R Shenoy
2007-04-20 11:59 ` Rafael J. Wysocki
2007-04-20 12:26 ` Gautham R Shenoy
2007-04-20 12:50 ` Rafael J. Wysocki
2007-04-20 17:30 ` Andrew Morton
2007-04-20 18:31 ` Ingo Molnar
2007-04-20 21:13 ` Rafael J. Wysocki
2007-04-22 19:28 ` [RFC][PATCH -mm 0/3] Separate freezer flags Rafael J. Wysocki
2007-04-22 19:33 ` [RFC][PATCH -mm 1/3] Separate freezer from PM code Rafael J. Wysocki
2007-04-23 10:41 ` Pavel Machek
2007-04-22 19:39 ` [RFC][PATCH -mm 2/3] freezer: Introduce freezer_flags Rafael J. Wysocki
2007-04-22 21:14 ` Paul Jackson
2007-04-22 22:14 ` Rafael J. Wysocki
2007-04-22 22:31 ` Paul Jackson
2007-04-23 3:18 ` Satyam Sharma
2007-04-23 4:09 ` Satyam Sharma
2007-04-23 14:19 ` Gautham R Shenoy
2007-04-23 18:49 ` Rafael J. Wysocki
2007-04-23 19:06 ` Rafael J. Wysocki
2007-04-23 10:50 ` Pavel Machek
2007-04-23 13:17 ` Gautham R Shenoy
2007-04-23 19:57 ` Rafael J. Wysocki
2007-04-23 22:23 ` Oleg Nesterov
2007-04-23 22:40 ` Rafael J. Wysocki
2007-04-23 22:41 ` Gautham R Shenoy
2007-04-23 22:55 ` Rafael J. Wysocki
2007-04-23 22:55 ` Oleg Nesterov
2007-04-23 23:10 ` Rafael J. Wysocki
2007-04-23 23:19 ` Oleg Nesterov
2007-04-24 11:32 ` Rafael J. Wysocki
2007-04-22 19:40 ` [RFC][PATCH -mm 3/3] freezer: Fix problem with kthread_stop Rafael J. Wysocki
2007-04-23 10:40 ` Pavel Machek
2007-04-23 19:50 ` Rafael J. Wysocki
2007-04-23 12:35 ` Gautham R Shenoy
2007-04-23 19:03 ` Oleg Nesterov
2007-04-23 20:05 ` Rafael J. Wysocki
2007-04-23 19:55 ` Rafael J. Wysocki
2007-04-23 20:46 ` Oleg Nesterov
2007-04-23 21:16 ` Gautham R Shenoy
2007-04-23 21:30 ` Rafael J. Wysocki
2007-04-20 21:20 ` [RFC PATCH(experimental) 2/2] Fix freezer-kthread_stop race Oleg Nesterov
2007-04-20 21:45 ` Rafael J. Wysocki
2007-04-20 10:46 ` Gautham R Shenoy [this message]
2007-04-21 9:37 ` Pavel Machek
2007-04-20 21:12 ` Oleg Nesterov
2007-04-23 10:38 ` Gautham R Shenoy
2007-04-23 18:39 ` Oleg Nesterov
2007-04-23 20:34 ` Gautham R Shenoy
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=20070420104647.GA11290@in.ibm.com \
--to=ego@in.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=paulmck@us.ibm.com \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=vatsa@in.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox