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 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.