[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1170297763.32500.7.camel@nigel.suspend2.net>
Date: Thu, 01 Feb 2007 13:42:42 +1100
From: Nigel Cunningham <nigel@...el.suspend2.net>
To: paulmck@...ux.vnet.ibm.com
Cc: linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
dipankar@...ibm.com, tytso@...ibm.com, dvhltc@...ibm.com,
oleg@...sign.ru, twoerner.k@...il.com, josh@...edesktop.org,
billh@...ppy.monkey.org, nielsen.esben@...glemail.com,
corbet@....net
Subject: Re: [RFC PATCH -rt 2/2] RCU priority boosting additions to
rcutorture
Hi Paul.
On Wed, 2007-01-31 at 18:31 -0800, Paul E. McKenney wrote:
> Good to hear from you, Nigel!
Thanks :)
> Should indeed be OK to freeze during suspend/hibernate. Will my
> schedule_timeout_interruptible() be sufficient to allow the freeze
> to happen, or do I need to add an explicit try_to_freeze()?
You need a try_to_freeze() - the process has to enter the refrigerator()
function to be counted as frozen.
> Ah, and I probably need to use the same trick that mtd_blktrans_thread()
> does to avoid having all my sleeps killed of by an errant signal:
>
> spin_lock_irq(¤t->sighand->siglock);
> sigfillset(¤t->blocked);
> recalc_sigpending();
> spin_unlock_irq(¤t->sighand->siglock);
>
> Or is such paranoia unnecessary?
Yeah. try_to_freeze() is a function now, so you can do something if
(try_to_freeze()) goto sleep_again if you so desire.
Regards,
Nigel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists