public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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(&current->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!"

  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