Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Wed, 2007-05-30 at 00:13 +0200, Rafael J. Wysocki wrote:
> On Tuesday, 29 May 2007 14:59, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Tue, 2007-05-29 at 14:15 +0200, Rafael J. Wysocki wrote:
> > > Please have a look at the current version of the patch (appended).
> > > 
> > > I have followed the Nigel's suggestion not to change the current behavior
> > > in this patch (I'll add a couple of patches removing the freezability from
> > > some kernel threads), with one exception: I couldn't figure out any reason
> > > to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .
> > 
> > Thanks. IIRC, svcsock is related to the NFS server code.
> > 
> > > I've also added a piece of documentation, freezing-of-tasks.txt .  Please
> > > see if it's not missing anything (I'd like it to be quite complete).
> > 
> > [...]
> > 
> > Mostly just grammar and the odd typo. On the whole, it's really well
> > written and perfectly readable - great job!
> 
> Thanks a lot for all of the comments, they are really helpful. :-)

Thank you for doing all this work in the first place!

Acked-by: Nigel Cunningham <[EMAIL PROTECTED]>

Regards,

Nigel


signature.asc
Description: This is a digitally signed message part

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Tuesday, 29 May 2007 14:59, Nigel Cunningham wrote:
> Hi.
> 
> On Tue, 2007-05-29 at 14:15 +0200, Rafael J. Wysocki wrote:
> > Please have a look at the current version of the patch (appended).
> > 
> > I have followed the Nigel's suggestion not to change the current behavior
> > in this patch (I'll add a couple of patches removing the freezability from
> > some kernel threads), with one exception: I couldn't figure out any reason
> > to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .
> 
> Thanks. IIRC, svcsock is related to the NFS server code.
> 
> > I've also added a piece of documentation, freezing-of-tasks.txt .  Please
> > see if it's not missing anything (I'd like it to be quite complete).
> 
> [...]
> 
> Mostly just grammar and the odd typo. On the whole, it's really well
> written and perfectly readable - great job!

Thanks a lot for all of the comments, they are really helpful. :-)

> > Index: linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
> > ===
> > --- /dev/null
> > +++ linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
> > @@ -0,0 +1,160 @@
> > +Freezing of tasks
> > +   (C) 2007 Rafael J. Wysocki <[EMAIL PROTECTED]>, GPL
> > +
> > +I. What is the freezing of tasks?
> > +
> > +The freezing of tasks is a mechanism by which user space processes and some
> > +kernel threads are controlled during hibernation or system-wide suspend 
> > (on some
> > +architectures).
> > +
> > +II. How it works?
> 
> How does it work?

Yup.

[--snip--]
> > +1. The principal reason is to prevent filesystems from being damaged after
> > +hibernation.  Namely, for now we have no simple means of checkpointing
> 
> s/Namely, for now/At the moment/
> 
> No simple means or no means at all? Are you thinking of bdev freezing?

No, of LVM snapshot functionality.

> > +filesystems, so if there are any modifications made to filesystem data 
> > and/or
> > +metadata on disks, we usually cannot bring them back to the state from 
> > before
> 
> If the above is changed, I'd remove 'usually' here.

Removed.

[-- Skipped some simple comments that have been followed --]
> > +Although Linus Torvalds doesn't like the freezing of tasks, he said this 
> > in one
> > +of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
> > +
> > +'> Why we freeze tasks at all or why we freeze kernel threads?
> > +
> > +In many ways, "at all".
> 
> I found these first two lines confusing - I though the "Why we
> freeze..." was Linus, rather than a quotation he was responding to. I'd
> suggest starting the quote at what follows this point... but then as I
> read further, I can see the quote is necessary to make sense of the
> second paragraph below. Perhaps the best way would to put a line before
> the "Why we freeze..." indicating that you're being quoted there.

Well, I've tried to make this a bit cleaner (please see the patch below).

> > +I _do_ realize the IO request queue issues, and that we cannot actually do
> > +s2ram with some devices in the middle of a DMA.  So we want to be able to
> > +avoid *that*, there's no question about that.  And I suspect that stopping
> > +user threads and then waiting for a sync is practically one of the easier
> > +ways to do so.
> > +
> > +So in practice, the "at all" may become a "why freeze kernel threads?" and
> > +freezing user threads I don't find really objectionable.'
> 
> Oh, and double quotes should surround the whole quote, with single
> quotes replacing the double quotes in the quotation. Hope all those
> 'quote's aren't confusing! :)

Fixed.

[-- Skipped some simple comments that have been followed --]
> > +Suppose, however, that the firmware file is located on a filesystem 
> > accessible
> > +only through the device that needs the firmware.  In that case, the system 
> > won't
> > +be able to work normally after the restore regardless of whether or not the
> > +freezing of tasks is used.  Consequently, the problem is not really 
> > related to
> > +the freezing of tasks, since it generally exists regardless.  [The 
> > solution to
> > +this particular problem is to keep the firmware in memory after it's 
> > loaded for
> > +the first time and upload if from memory to the device whenever necessary.]
> 
> I understand the logic and agree with that you're trying to say in this
> last example, but think the example is faulty. If the firmware is on a
> filesystem accessible only through the device that needs the firmware,
> then you wouldn't be able to bring it up in the first place.

Very true.  I've changed that in the updated patch (appended).

Thanks again,
Rafael


Hi,

On Tuesday, 29 May 2007 13:31, Pavel Machek wrote:
> Hi!
> 
> > > > Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
> > > > +++ 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Tuesday, 29 May 2007 14:48, Pavel Machek wrote:
> Hi!
> 
> > > Well.. it can write anywhere it wants (filesystem or not) as long as
> > > the system is not going to be confused after resume by its caches not
> > > matching on-disk state. I'd prefer it not to write anywhere at all.
> > 
> > OK
> > 
> > Please have a look at the current version of the patch (appended).
> > 
> > I have followed the Nigel's suggestion not to change the current behavior
> > in this patch (I'll add a couple of patches removing the freezability from
> > some kernel threads), with one exception: I couldn't figure out any reason
> > to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .
> 
> It probably broke suspend at some point... leave it there. Processes
> can stay in D period, waiting for NFS server to come back.
> 
> and yes, we want nfs threads frozen, too (and anything that talks to
> network). Speaking to nfs servers while we are suspending the machine
> is not nice, and if that continues after snapshot, we'll act as a very
> confused machine to the outside...

OK, I've added set_freezable() to the NFS-related threads.

[Updated patch is in the reply to Nigel.]

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Linus Torvalds]

On Tue, 29 May 2007, Rafael J. Wysocki wrote:
>
>  64 files changed, 230 insertions(+), 113 deletions(-)

Heh. Your previous patch removed more lines than it added, this one adds 
more lines than it removes. Snif..

I realize that it's all from that Documentation update:

 Documentation/power/freezing-of-tasks.txt |  160 ++
 Documentation/power/kernel_threads.txt|   40 ---
 Documentation/power/swsusp.txt|   18 ---

so it's all good. Anyway, I'll happily do this (along with the patch to 
not do freezer at all for STR) after 2.6.22 is out, but until then I'll 
obviously be ignoring the patches flying around..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

> > Well.. it can write anywhere it wants (filesystem or not) as long as
> > the system is not going to be confused after resume by its caches not
> > matching on-disk state. I'd prefer it not to write anywhere at all.
> 
> OK
> 
> Please have a look at the current version of the patch (appended).
> 
> I have followed the Nigel's suggestion not to change the current behavior
> in this patch (I'll add a couple of patches removing the freezability from
> some kernel threads), with one exception: I couldn't figure out any reason
> to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .

It probably broke suspend at some point... leave it there. Processes
can stay in D period, waiting for NFS server to come back.

and yes, we want nfs threads frozen, too (and anything that talks to
network). Speaking to nfs servers while we are suspending the machine
is not nice, and if that continues after snapshot, we'll act as a very
confused machine to the outside...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Tue, 2007-05-29 at 14:15 +0200, Rafael J. Wysocki wrote:
> Please have a look at the current version of the patch (appended).
> 
> I have followed the Nigel's suggestion not to change the current behavior
> in this patch (I'll add a couple of patches removing the freezability from
> some kernel threads), with one exception: I couldn't figure out any reason
> to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .

Thanks. IIRC, svcsock is related to the NFS server code.

> I've also added a piece of documentation, freezing-of-tasks.txt .  Please
> see if it's not missing anything (I'd like it to be quite complete).

[...]

Mostly just grammar and the odd typo. On the whole, it's really well
written and perfectly readable - great job!

> Index: linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
> ===
> --- /dev/null
> +++ linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
> @@ -0,0 +1,160 @@
> +Freezing of tasks
> + (C) 2007 Rafael J. Wysocki <[EMAIL PROTECTED]>, GPL
> +
> +I. What is the freezing of tasks?
> +
> +The freezing of tasks is a mechanism by which user space processes and some
> +kernel threads are controlled during hibernation or system-wide suspend (on 
> some
> +architectures).
> +
> +II. How it works?

How does it work?

> +
> +There are four per-task flags used for that, PF_NOFREEZE, PF_FROZEN, 
> TIF_FREEZE
> +and PF_FREEZER_SKIP (the last one is auxiliary).  The tasks that have
> +PF_NOFREEZE unset (all user space processes and some kernel threads) are
> +regarded as 'freezable' and treated in a special way before the system 
> enters a
> +suspend state as well as before a hibernation image is created (in what 
> follows
> +we only consider hibernation, but the description also applies to suspend).
> +
> +Namely, as the first step of the hibernation procedure the function
> +freeze_processes() (defined in kernel/power/process.c) is called.  It 
> executes
> +try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
> +sends a fake signal to each of them.  A task that receives such a signal and 
> has
> +TIF_FREEZE set, should react to it by calling the refrigerator() function
> +(defined in kernel/power/process.c), which sets the task's PF_FROZEN flag,
> +changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN 
> is
> +cleared for it.  Then, we say that the task is 'frozen' and therefore the 
> set of
> +functions handling this mechanism is called 'the freezer' (these functions 
> are
> +defined in kernel/power/process.c and include/linux/freezer.h).  User space
> +processes are generally frozen before kernel threads.
> +
> +It is not recommended to call refrigerator() directly.  Instead, it is
> +recommended to use the try_to_freeze() function (defined in
> +include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes 
> the
> +task enter refrigerator() if the flag is set.
> +
> +For user space processes try_to_freeze() is called automatically from the
> +signal-handling code, but the freezable kernel threads need to call it
> +explicitly in suitable places.  The code to do this may look like the 
> following:
> +
> + do {
> + hub_events();
> + wait_event_interruptible(khubd_wait,
> + !list_empty(_event_list));
> + try_to_freeze();
> + } while (!signal_pending(current));
> +
> +(from drivers/usb/core/hub.c::hub_thread()).
> +
> +If a freezable kernel thread fails to call try_to_freeze() after the freezer 
> has
> +set TIF_FREEZE for it, the freezing of tasks will fail and the entire
> +hibernation operation will be cancelled.  For this reason, freezable kernel
> +threads must call try_to_freeze() somewhere.
> +
> +After the system memory state has been restored from a hibernation image and
> +devices have been reinitialized, the function thaw_processes() is called in
> +order to clear the PF_FROZEN flag for each frozen task.  Then, the tasks that
> +have been frozen leave refrigerator() and continue running.
> +
> +III. Which kernel threads are freezable?
> +
> +Kernel threads are not freezable by default.  However, a kernel thread may 
> clear
> +PF_NOFREEZE for itself by calling set_freezable() (the resetting of 
> PF_NOFREEZE
> +directly is strongly discouraged).  From this point it is regarded as 
> freezable
> +and must call try_to_freeze() in a suitable place.
> +
> +IV. Why do we do that?
> +
> +Generally speaking, there is a couple of reasons to use the freezing of 
> tasks:
> +
> +1. The principal reason is to prevent filesystems from being damaged after
> +hibernation.  Namely, for now we have no simple means of checkpointing

s/Namely, for now/At the moment/

No simple means or no means at all? Are you thinking of bdev freezing?

> +filesystems, so if there are any modifications made to filesystem data and/or
> +metadata on disks, we usually 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

Hi,

On Tuesday, 29 May 2007 13:31, Pavel Machek wrote:
> Hi!
> 
> > > > Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
> > > > +++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> > > > @@ -1,13 +1,22 @@
> > > > -KERNEL THREADS
> > > > +The Freezer and Kernel Threads
> > > >  
> > > > -
> > > > -Freezer
> > > > -
> > > > -Upon entering a suspended state the system will freeze all
> > > > -tasks. This is done by delivering pseudosignals. This affects
> > > > -kernel threads, too. To successfully freeze a kernel thread
> > > > -the thread has to check for the pseudosignal and enter the
> > > > -refrigerator. Code to do this looks like this:
> > > > +Before entering a system-wide suspend state as well as before creating 
> > > > a
> > > > +hibernation snapshot image the system will freeze all tasks, which is 
> > > > done
> > > > +by delivering fake signals.  This affects kernel threads too, but they 
> > > > won't be
> > > > +frozen unless they declare that they want to.  For this purpose
> > > 
> > > Well... and unless thread that does disk writes or DMA _wants_ to, you
> > > have nice disk corruption... It should be pointed out that it is not
> > > voluntary for those types of threads.
> > 
> > Well, that really depends.
> > 
> > I think the only thing that must not be written to disk is filesystem stuff.
> > The other things (eg. writing directly to block devices etc.) doesn't hurt 
> > us.
> 
> Well.. it can write anywhere it wants (filesystem or not) as long as
> the system is not going to be confused after resume by its caches not
> matching on-disk state. I'd prefer it not to write anywhere at all.

OK

Please have a look at the current version of the patch (appended).

I have followed the Nigel's suggestion not to change the current behavior
in this patch (I'll add a couple of patches removing the freezability from
some kernel threads), with one exception: I couldn't figure out any reason
to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .

I've also added a piece of documentation, freezing-of-tasks.txt .  Please
see if it's not missing anything (I'd like it to be quite complete).

Greetings,
Rafael


Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 Documentation/power/freezing-of-tasks.txt |  160 ++
 Documentation/power/kernel_threads.txt|   40 ---
 Documentation/power/swsusp.txt|   18 ---
 arch/i386/kernel/apm.c|1 
 arch/i386/kernel/io_apic.c|1 
 drivers/block/loop.c  |7 -
 drivers/block/pktcdvd.c   |1 
 drivers/char/apm-emulation.c  |   11 --
 drivers/char/hvc_console.c|1 
 drivers/edac/edac_mc.c|1 
 drivers/ieee1394/ieee1394_core.c  |2 
 drivers/ieee1394/nodemgr.c|1 
 drivers/input/gameport/gameport.c |1 
 drivers/input/serio/serio.c   |1 
 drivers/input/touchscreen/ucb1400_ts.c|1 
 drivers/macintosh/therm_adt746x.c |1 
 drivers/macintosh/windfarm_core.c |1 
 drivers/md/md.c   |1 
 drivers/media/dvb/dvb-core/dvb_frontend.c |1 
 drivers/media/video/cx88/cx88-tvaudio.c   |1 
 drivers/media/video/msp3400-kthreads.c|5 
 drivers/media/video/tvaudio.c |2 
 drivers/media/video/video-buf-dvb.c   |1 
 drivers/media/video/vivi.c|1 
 drivers/mfd/ucb1x00-ts.c  |1 
 drivers/mmc/card/queue.c  |6 -
 drivers/mtd/mtd_blkdevs.c |2 
 drivers/mtd/ubi/wl.c  |1 
 drivers/net/wireless/airo.c   |3 
 drivers/net/wireless/libertas/main.c  |1 
 drivers/pcmcia/cs.c   |1 
 drivers/pnp/pnpbios/core.c|1 
 drivers/scsi/libsas/sas_scsi_host.c   |2 
 drivers/scsi/scsi_error.c |2 
 drivers/usb/atm/ueagle-atm.c  |1 
 drivers/usb/core/hub.c|1 
 drivers/usb/gadget/file_storage.c |2 
 drivers/usb/storage/usb.c |3 
 drivers/video/ps3fb.c |1 
 drivers/w1/w1.c   |1 
 fs/cifs/cifsfs.c  |1 
 fs/cifs/connect.c |1 
 fs/jffs2/background.c |1 
 fs/lockd/svc.c|2 
 fs/xfs/linux-2.6/xfs_super.c  |1 
 include/linux/freezer.h   |9 +
 init/do_mounts_initrd.c   |7 -
 kernel/audit.c|1 
 kernel/exit.c |5 
 kernel/fork.c |2 
 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

> > > Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> > > ===
> > > --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
> > > +++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> > > @@ -1,13 +1,22 @@
> > > -KERNEL THREADS
> > > +The Freezer and Kernel Threads
> > >  
> > > -
> > > -Freezer
> > > -
> > > -Upon entering a suspended state the system will freeze all
> > > -tasks. This is done by delivering pseudosignals. This affects
> > > -kernel threads, too. To successfully freeze a kernel thread
> > > -the thread has to check for the pseudosignal and enter the
> > > -refrigerator. Code to do this looks like this:
> > > +Before entering a system-wide suspend state as well as before creating a
> > > +hibernation snapshot image the system will freeze all tasks, which is 
> > > done
> > > +by delivering fake signals.  This affects kernel threads too, but they 
> > > won't be
> > > +frozen unless they declare that they want to.  For this purpose
> > 
> > Well... and unless thread that does disk writes or DMA _wants_ to, you
> > have nice disk corruption... It should be pointed out that it is not
> > voluntary for those types of threads.
> 
> Well, that really depends.
> 
> I think the only thing that must not be written to disk is filesystem stuff.
> The other things (eg. writing directly to block devices etc.) doesn't hurt us.

Well.. it can write anywhere it wants (filesystem or not) as long as
the system is not going to be confused after resume by its caches not
matching on-disk state. I'd prefer it not to write anywhere at all.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

   Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
   ===
   --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
   +++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
   @@ -1,13 +1,22 @@
   -KERNEL THREADS
   +The Freezer and Kernel Threads

   -
   -Freezer
   -
   -Upon entering a suspended state the system will freeze all
   -tasks. This is done by delivering pseudosignals. This affects
   -kernel threads, too. To successfully freeze a kernel thread
   -the thread has to check for the pseudosignal and enter the
   -refrigerator. Code to do this looks like this:
   +Before entering a system-wide suspend state as well as before creating a
   +hibernation snapshot image the system will freeze all tasks, which is 
   done
   +by delivering fake signals.  This affects kernel threads too, but they 
   won't be
   +frozen unless they declare that they want to.  For this purpose
  
  Well... and unless thread that does disk writes or DMA _wants_ to, you
  have nice disk corruption... It should be pointed out that it is not
  voluntary for those types of threads.
 
 Well, that really depends.
 
 I think the only thing that must not be written to disk is filesystem stuff.
 The other things (eg. writing directly to block devices etc.) doesn't hurt us.

Well.. it can write anywhere it wants (filesystem or not) as long as
the system is not going to be confused after resume by its caches not
matching on-disk state. I'd prefer it not to write anywhere at all.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

Hi,

On Tuesday, 29 May 2007 13:31, Pavel Machek wrote:
 Hi!
 
Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
===
--- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
+++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
@@ -1,13 +1,22 @@
-KERNEL THREADS
+The Freezer and Kernel Threads
 
-
-Freezer
-
-Upon entering a suspended state the system will freeze all
-tasks. This is done by delivering pseudosignals. This affects
-kernel threads, too. To successfully freeze a kernel thread
-the thread has to check for the pseudosignal and enter the
-refrigerator. Code to do this looks like this:
+Before entering a system-wide suspend state as well as before creating 
a
+hibernation snapshot image the system will freeze all tasks, which is 
done
+by delivering fake signals.  This affects kernel threads too, but they 
won't be
+frozen unless they declare that they want to.  For this purpose
   
   Well... and unless thread that does disk writes or DMA _wants_ to, you
   have nice disk corruption... It should be pointed out that it is not
   voluntary for those types of threads.
  
  Well, that really depends.
  
  I think the only thing that must not be written to disk is filesystem stuff.
  The other things (eg. writing directly to block devices etc.) doesn't hurt 
  us.
 
 Well.. it can write anywhere it wants (filesystem or not) as long as
 the system is not going to be confused after resume by its caches not
 matching on-disk state. I'd prefer it not to write anywhere at all.

OK

Please have a look at the current version of the patch (appended).

I have followed the Nigel's suggestion not to change the current behavior
in this patch (I'll add a couple of patches removing the freezability from
some kernel threads), with one exception: I couldn't figure out any reason
to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .

I've also added a piece of documentation, freezing-of-tasks.txt .  Please
see if it's not missing anything (I'd like it to be quite complete).

Greetings,
Rafael


Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
 Documentation/power/freezing-of-tasks.txt |  160 ++
 Documentation/power/kernel_threads.txt|   40 ---
 Documentation/power/swsusp.txt|   18 ---
 arch/i386/kernel/apm.c|1 
 arch/i386/kernel/io_apic.c|1 
 drivers/block/loop.c  |7 -
 drivers/block/pktcdvd.c   |1 
 drivers/char/apm-emulation.c  |   11 --
 drivers/char/hvc_console.c|1 
 drivers/edac/edac_mc.c|1 
 drivers/ieee1394/ieee1394_core.c  |2 
 drivers/ieee1394/nodemgr.c|1 
 drivers/input/gameport/gameport.c |1 
 drivers/input/serio/serio.c   |1 
 drivers/input/touchscreen/ucb1400_ts.c|1 
 drivers/macintosh/therm_adt746x.c |1 
 drivers/macintosh/windfarm_core.c |1 
 drivers/md/md.c   |1 
 drivers/media/dvb/dvb-core/dvb_frontend.c |1 
 drivers/media/video/cx88/cx88-tvaudio.c   |1 
 drivers/media/video/msp3400-kthreads.c|5 
 drivers/media/video/tvaudio.c |2 
 drivers/media/video/video-buf-dvb.c   |1 
 drivers/media/video/vivi.c|1 
 drivers/mfd/ucb1x00-ts.c  |1 
 drivers/mmc/card/queue.c  |6 -
 drivers/mtd/mtd_blkdevs.c |2 
 drivers/mtd/ubi/wl.c  |1 
 drivers/net/wireless/airo.c   |3 
 drivers/net/wireless/libertas/main.c  |1 
 drivers/pcmcia/cs.c   |1 
 drivers/pnp/pnpbios/core.c|1 
 drivers/scsi/libsas/sas_scsi_host.c   |2 
 drivers/scsi/scsi_error.c |2 
 drivers/usb/atm/ueagle-atm.c  |1 
 drivers/usb/core/hub.c|1 
 drivers/usb/gadget/file_storage.c |2 
 drivers/usb/storage/usb.c |3 
 drivers/video/ps3fb.c |1 
 drivers/w1/w1.c   |1 
 fs/cifs/cifsfs.c  |1 
 fs/cifs/connect.c |1 
 fs/jffs2/background.c |1 
 fs/lockd/svc.c|2 
 fs/xfs/linux-2.6/xfs_super.c  |1 
 include/linux/freezer.h   |9 +
 init/do_mounts_initrd.c   |7 -
 kernel/audit.c|1 
 kernel/exit.c |5 
 kernel/fork.c |2 
 kernel/rcutorture.c   |3 
 kernel/rtmutex-tester.c   |1 
 kernel/sched.c 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Tue, 2007-05-29 at 14:15 +0200, Rafael J. Wysocki wrote:
 Please have a look at the current version of the patch (appended).
 
 I have followed the Nigel's suggestion not to change the current behavior
 in this patch (I'll add a couple of patches removing the freezability from
 some kernel threads), with one exception: I couldn't figure out any reason
 to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .

Thanks. IIRC, svcsock is related to the NFS server code.

 I've also added a piece of documentation, freezing-of-tasks.txt .  Please
 see if it's not missing anything (I'd like it to be quite complete).

[...]

Mostly just grammar and the odd typo. On the whole, it's really well
written and perfectly readable - great job!

 Index: linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
 ===
 --- /dev/null
 +++ linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
 @@ -0,0 +1,160 @@
 +Freezing of tasks
 + (C) 2007 Rafael J. Wysocki [EMAIL PROTECTED], GPL
 +
 +I. What is the freezing of tasks?
 +
 +The freezing of tasks is a mechanism by which user space processes and some
 +kernel threads are controlled during hibernation or system-wide suspend (on 
 some
 +architectures).
 +
 +II. How it works?

How does it work?

 +
 +There are four per-task flags used for that, PF_NOFREEZE, PF_FROZEN, 
 TIF_FREEZE
 +and PF_FREEZER_SKIP (the last one is auxiliary).  The tasks that have
 +PF_NOFREEZE unset (all user space processes and some kernel threads) are
 +regarded as 'freezable' and treated in a special way before the system 
 enters a
 +suspend state as well as before a hibernation image is created (in what 
 follows
 +we only consider hibernation, but the description also applies to suspend).
 +
 +Namely, as the first step of the hibernation procedure the function
 +freeze_processes() (defined in kernel/power/process.c) is called.  It 
 executes
 +try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
 +sends a fake signal to each of them.  A task that receives such a signal and 
 has
 +TIF_FREEZE set, should react to it by calling the refrigerator() function
 +(defined in kernel/power/process.c), which sets the task's PF_FROZEN flag,
 +changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN 
 is
 +cleared for it.  Then, we say that the task is 'frozen' and therefore the 
 set of
 +functions handling this mechanism is called 'the freezer' (these functions 
 are
 +defined in kernel/power/process.c and include/linux/freezer.h).  User space
 +processes are generally frozen before kernel threads.
 +
 +It is not recommended to call refrigerator() directly.  Instead, it is
 +recommended to use the try_to_freeze() function (defined in
 +include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes 
 the
 +task enter refrigerator() if the flag is set.
 +
 +For user space processes try_to_freeze() is called automatically from the
 +signal-handling code, but the freezable kernel threads need to call it
 +explicitly in suitable places.  The code to do this may look like the 
 following:
 +
 + do {
 + hub_events();
 + wait_event_interruptible(khubd_wait,
 + !list_empty(hub_event_list));
 + try_to_freeze();
 + } while (!signal_pending(current));
 +
 +(from drivers/usb/core/hub.c::hub_thread()).
 +
 +If a freezable kernel thread fails to call try_to_freeze() after the freezer 
 has
 +set TIF_FREEZE for it, the freezing of tasks will fail and the entire
 +hibernation operation will be cancelled.  For this reason, freezable kernel
 +threads must call try_to_freeze() somewhere.
 +
 +After the system memory state has been restored from a hibernation image and
 +devices have been reinitialized, the function thaw_processes() is called in
 +order to clear the PF_FROZEN flag for each frozen task.  Then, the tasks that
 +have been frozen leave refrigerator() and continue running.
 +
 +III. Which kernel threads are freezable?
 +
 +Kernel threads are not freezable by default.  However, a kernel thread may 
 clear
 +PF_NOFREEZE for itself by calling set_freezable() (the resetting of 
 PF_NOFREEZE
 +directly is strongly discouraged).  From this point it is regarded as 
 freezable
 +and must call try_to_freeze() in a suitable place.
 +
 +IV. Why do we do that?
 +
 +Generally speaking, there is a couple of reasons to use the freezing of 
 tasks:
 +
 +1. The principal reason is to prevent filesystems from being damaged after
 +hibernation.  Namely, for now we have no simple means of checkpointing

s/Namely, for now/At the moment/

No simple means or no means at all? Are you thinking of bdev freezing?

 +filesystems, so if there are any modifications made to filesystem data and/or
 +metadata on disks, we usually cannot bring them back to the state from before

If the above is changed, I'd remove 'usually' here.

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

  Well.. it can write anywhere it wants (filesystem or not) as long as
  the system is not going to be confused after resume by its caches not
  matching on-disk state. I'd prefer it not to write anywhere at all.
 
 OK
 
 Please have a look at the current version of the patch (appended).
 
 I have followed the Nigel's suggestion not to change the current behavior
 in this patch (I'll add a couple of patches removing the freezability from
 some kernel threads), with one exception: I couldn't figure out any reason
 to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .

It probably broke suspend at some point... leave it there. Processes
can stay in D period, waiting for NFS server to come back.

and yes, we want nfs threads frozen, too (and anything that talks to
network). Speaking to nfs servers while we are suspending the machine
is not nice, and if that continues after snapshot, we'll act as a very
confused machine to the outside...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Linus Torvalds]

On Tue, 29 May 2007, Rafael J. Wysocki wrote:

  64 files changed, 230 insertions(+), 113 deletions(-)

Heh. Your previous patch removed more lines than it added, this one adds 
more lines than it removes. Snif..

I realize that it's all from that Documentation update:

 Documentation/power/freezing-of-tasks.txt |  160 ++
 Documentation/power/kernel_threads.txt|   40 ---
 Documentation/power/swsusp.txt|   18 ---

so it's all good. Anyway, I'll happily do this (along with the patch to 
not do freezer at all for STR) after 2.6.22 is out, but until then I'll 
obviously be ignoring the patches flying around..

Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Tuesday, 29 May 2007 14:48, Pavel Machek wrote:
 Hi!
 
   Well.. it can write anywhere it wants (filesystem or not) as long as
   the system is not going to be confused after resume by its caches not
   matching on-disk state. I'd prefer it not to write anywhere at all.
  
  OK
  
  Please have a look at the current version of the patch (appended).
  
  I have followed the Nigel's suggestion not to change the current behavior
  in this patch (I'll add a couple of patches removing the freezability from
  some kernel threads), with one exception: I couldn't figure out any reason
  to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .
 
 It probably broke suspend at some point... leave it there. Processes
 can stay in D period, waiting for NFS server to come back.
 
 and yes, we want nfs threads frozen, too (and anything that talks to
 network). Speaking to nfs servers while we are suspending the machine
 is not nice, and if that continues after snapshot, we'll act as a very
 confused machine to the outside...

OK, I've added set_freezable() to the NFS-related threads.

[Updated patch is in the reply to Nigel.]

Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Tuesday, 29 May 2007 14:59, Nigel Cunningham wrote:
 Hi.
 
 On Tue, 2007-05-29 at 14:15 +0200, Rafael J. Wysocki wrote:
  Please have a look at the current version of the patch (appended).
  
  I have followed the Nigel's suggestion not to change the current behavior
  in this patch (I'll add a couple of patches removing the freezability from
  some kernel threads), with one exception: I couldn't figure out any reason
  to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .
 
 Thanks. IIRC, svcsock is related to the NFS server code.
 
  I've also added a piece of documentation, freezing-of-tasks.txt .  Please
  see if it's not missing anything (I'd like it to be quite complete).
 
 [...]
 
 Mostly just grammar and the odd typo. On the whole, it's really well
 written and perfectly readable - great job!

Thanks a lot for all of the comments, they are really helpful. :-)

  Index: linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
  ===
  --- /dev/null
  +++ linux-2.6.22-rc3/Documentation/power/freezing-of-tasks.txt
  @@ -0,0 +1,160 @@
  +Freezing of tasks
  +   (C) 2007 Rafael J. Wysocki [EMAIL PROTECTED], GPL
  +
  +I. What is the freezing of tasks?
  +
  +The freezing of tasks is a mechanism by which user space processes and some
  +kernel threads are controlled during hibernation or system-wide suspend 
  (on some
  +architectures).
  +
  +II. How it works?
 
 How does it work?

Yup.

[--snip--]
  +1. The principal reason is to prevent filesystems from being damaged after
  +hibernation.  Namely, for now we have no simple means of checkpointing
 
 s/Namely, for now/At the moment/
 
 No simple means or no means at all? Are you thinking of bdev freezing?

No, of LVM snapshot functionality.

  +filesystems, so if there are any modifications made to filesystem data 
  and/or
  +metadata on disks, we usually cannot bring them back to the state from 
  before
 
 If the above is changed, I'd remove 'usually' here.

Removed.

[-- Skipped some simple comments that have been followed --]
  +Although Linus Torvalds doesn't like the freezing of tasks, he said this 
  in one
  +of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
  +
  +' Why we freeze tasks at all or why we freeze kernel threads?
  +
  +In many ways, at all.
 
 I found these first two lines confusing - I though the Why we
 freeze... was Linus, rather than a quotation he was responding to. I'd
 suggest starting the quote at what follows this point... but then as I
 read further, I can see the quote is necessary to make sense of the
 second paragraph below. Perhaps the best way would to put a line before
 the Why we freeze... indicating that you're being quoted there.

Well, I've tried to make this a bit cleaner (please see the patch below).

  +I _do_ realize the IO request queue issues, and that we cannot actually do
  +s2ram with some devices in the middle of a DMA.  So we want to be able to
  +avoid *that*, there's no question about that.  And I suspect that stopping
  +user threads and then waiting for a sync is practically one of the easier
  +ways to do so.
  +
  +So in practice, the at all may become a why freeze kernel threads? and
  +freezing user threads I don't find really objectionable.'
 
 Oh, and double quotes should surround the whole quote, with single
 quotes replacing the double quotes in the quotation. Hope all those
 'quote's aren't confusing! :)

Fixed.

[-- Skipped some simple comments that have been followed --]
  +Suppose, however, that the firmware file is located on a filesystem 
  accessible
  +only through the device that needs the firmware.  In that case, the system 
  won't
  +be able to work normally after the restore regardless of whether or not the
  +freezing of tasks is used.  Consequently, the problem is not really 
  related to
  +the freezing of tasks, since it generally exists regardless.  [The 
  solution to
  +this particular problem is to keep the firmware in memory after it's 
  loaded for
  +the first time and upload if from memory to the device whenever necessary.]
 
 I understand the logic and agree with that you're trying to say in this
 last example, but think the example is faulty. If the firmware is on a
 filesystem accessible only through the device that needs the firmware,
 then you wouldn't be able to bring it up in the first place.

Very true.  I've changed that in the updated patch (appended).

Thanks again,
Rafael


Hi,

On Tuesday, 29 May 2007 13:31, Pavel Machek wrote:
 Hi!
 
Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
===
--- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
+++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
@@ -1,13 +1,22 @@
-KERNEL THREADS
+The Freezer and Kernel Threads
 
-
-Freezer
-
-Upon entering a suspended state the 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Wed, 2007-05-30 at 00:13 +0200, Rafael J. Wysocki wrote:
 On Tuesday, 29 May 2007 14:59, Nigel Cunningham wrote:
  Hi.
  
  On Tue, 2007-05-29 at 14:15 +0200, Rafael J. Wysocki wrote:
   Please have a look at the current version of the patch (appended).
   
   I have followed the Nigel's suggestion not to change the current behavior
   in this patch (I'll add a couple of patches removing the freezability from
   some kernel threads), with one exception: I couldn't figure out any reason
   to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .
  
  Thanks. IIRC, svcsock is related to the NFS server code.
  
   I've also added a piece of documentation, freezing-of-tasks.txt .  Please
   see if it's not missing anything (I'd like it to be quite complete).
  
  [...]
  
  Mostly just grammar and the odd typo. On the whole, it's really well
  written and perfectly readable - great job!
 
 Thanks a lot for all of the comments, they are really helpful. :-)

Thank you for doing all this work in the first place!

Acked-by: Nigel Cunningham [EMAIL PROTECTED]

Regards,

Nigel


signature.asc
Description: This is a digitally signed message part

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Tue, 2007-05-29 at 00:51 +0200, Rafael J. Wysocki wrote:
> > The copy_flags routine changes another process's flags - that's why
> I
> > was suggesting this.
> 
> Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there,
> not adding anything new. :-)

Doh! Sorry :)

Nigel


signature.asc
Description: This is a digitally signed message part

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 23:26, Nigel Cunningham wrote:
> Hi.
> 
> On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
> > On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> > > Hello!
> > > 
> > > In reply to your more recent message, I had looked but not tried, so
> > > didn't feel in a position to reply yet.
> > > 
> > > On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> > > >  63 files changed, 78 insertions(+), 138 deletions(-)
> > > 
> > > Well, that looks good, for a start :)
> > > 
> > > > Index: linux-2.6.22-rc3/kernel/exit.c
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > > > +++ linux-2.6.22-rc3/kernel/exit.c
> > > > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> > > >  * they would be locked into memory.
> > > >  */
> > > > exit_mm(current);
> > > > +   /*
> > > > +* We don't want to have TIF_FREEZE set if the system-wide 
> > > > hibernation
> > > > +* or suspend transision begins right now.
> > > > +*/
> > > > +   current->flags |= PF_NOFREEZE;
> > > 
> > > s/transision/transition
> > 
> > Thanks, will fix.
> > 
> > > > set_special_pids(1, 1);
> > > > proc_clear_tty(current);
> > > > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > > > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > > > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > > > return !!(p->flags & PF_FREEZER_SKIP);
> > > >  }
> > > >  
> > > > +/*
> > > > + * Tell the freezer that the current task should be frozen by it
> > > > + */
> > > > +static inline void set_freezable(void)
> > > > +{
> > > > +   current->flags &= ~PF_NOFREEZE;
> > > > +}
> > > > +
> > > 
> > > Given the clearing of the flag above, should we just have a
> > > set_unfreezeable here that's used above (and potentially elsewhere)...
> > > (reads more)... or more generic set_[un]freezeable(task_struct *p)
> > > routines that could also be used in copy_flags below?
> > 
> > Yes, I can introduce set_unfreezeable(), although that would be used in
> > a couple of places only.
> > 
> > I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
> > since only current is allowed to set/unset its flags.
> 
> The copy_flags routine changes another process's flags - that's why I
> was suggesting this.

Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there,
not adding anything new. :-)

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> > Hello!
> > 
> > In reply to your more recent message, I had looked but not tried, so
> > didn't feel in a position to reply yet.
> > 
> > On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> > >  63 files changed, 78 insertions(+), 138 deletions(-)
> > 
> > Well, that looks good, for a start :)
> > 
> > > Index: linux-2.6.22-rc3/kernel/exit.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > > +++ linux-2.6.22-rc3/kernel/exit.c
> > > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> > >* they would be locked into memory.
> > >*/
> > >   exit_mm(current);
> > > + /*
> > > +  * We don't want to have TIF_FREEZE set if the system-wide hibernation
> > > +  * or suspend transision begins right now.
> > > +  */
> > > + current->flags |= PF_NOFREEZE;
> > 
> > s/transision/transition
> 
> Thanks, will fix.
> 
> > >   set_special_pids(1, 1);
> > >   proc_clear_tty(current);
> > > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > > ===
> > > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > >   return !!(p->flags & PF_FREEZER_SKIP);
> > >  }
> > >  
> > > +/*
> > > + * Tell the freezer that the current task should be frozen by it
> > > + */
> > > +static inline void set_freezable(void)
> > > +{
> > > + current->flags &= ~PF_NOFREEZE;
> > > +}
> > > +
> > 
> > Given the clearing of the flag above, should we just have a
> > set_unfreezeable here that's used above (and potentially elsewhere)...
> > (reads more)... or more generic set_[un]freezeable(task_struct *p)
> > routines that could also be used in copy_flags below?
> 
> Yes, I can introduce set_unfreezeable(), although that would be used in
> a couple of places only.
> 
> I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
> since only current is allowed to set/unset its flags.

The copy_flags routine changes another process's flags - that's why I
was suggesting this.

> > >  #else
> > >  static inline int frozen(struct task_struct *p) { return 0; }
> > >  static inline int freezing(struct task_struct *p) { return 0; }
> > > @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) { 
> > >  static inline void freezer_do_not_count(void) {}
> > >  static inline void freezer_count(void) {}
> > >  static inline int freezer_should_skip(struct task_struct *p) { return 0; 
> > > }
> > > +static inline void set_freezable_current(void) {}
> 
> Ah, this is a mistake (wrong name).
> 
> > >  #endif
> > >  
> > >  #endif /* LINUX_FREEZER_H */
> > > Index: linux-2.6.22-rc3/kernel/fork.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/kernel/fork.c
> > > +++ linux-2.6.22-rc3/kernel/fork.c
> > > @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
> > >  {
> > >   unsigned long new_flags = p->flags;
> > >  
> > > - new_flags &= ~(PF_SUPERPRIV | PF_NOFREEZE);
> > > + new_flags &= ~PF_SUPERPRIV;
> > >   new_flags |= PF_FORKNOEXEC;
> > >   if (!(clone_flags & CLONE_PTRACE))
> > >   p->ptrace = 0;
> > > Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
> > > +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
> > >  
> > >   for ( ; ; ) {
> > >   time_remaining = schedule_timeout_interruptible(time_remaining);
> > > - try_to_freeze();
> > >   if (time_after(jiffies,
> > >   prev_balance_time+balanced_irq_interval)) {
> > >   preempt_disable();
> > 
> > I'm the one who is confused, aren't I? If I'm reading this right,
> > io_apic used to be frozen. After this patch, it will not be frozen. If
> > that's the intended behaviour, shouldn't this be two patches - one to
> > make kernel threads unfreezeable by default, and one to make threads
> > that were formerly freezeable unfreezeable?
> 
> Yes, I think you're right.  I tend to try to make too many changes in one
> shot. :-)
> 
> > 
> > [...]
> > 
> > > Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > ===
> > > --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
> > > +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > @@ -140,22 +140,6 @@ should be sent to the mailing list avail
> > >  website, and not to the Linux Kernel Mailing List. We are working
> > >  toward merging suspend2 into the mainline kernel.
> > >  
> > > -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> Hello!
> 
> In reply to your more recent message, I had looked but not tried, so
> didn't feel in a position to reply yet.
> 
> On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> >  63 files changed, 78 insertions(+), 138 deletions(-)
> 
> Well, that looks good, for a start :)
> 
> > Index: linux-2.6.22-rc3/kernel/exit.c
> > ===
> > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > +++ linux-2.6.22-rc3/kernel/exit.c
> > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> >  * they would be locked into memory.
> >  */
> > exit_mm(current);
> > +   /*
> > +* We don't want to have TIF_FREEZE set if the system-wide hibernation
> > +* or suspend transision begins right now.
> > +*/
> > +   current->flags |= PF_NOFREEZE;
> 
> s/transision/transition

Thanks, will fix.

> > set_special_pids(1, 1);
> > proc_clear_tty(current);
> > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > ===
> > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > return !!(p->flags & PF_FREEZER_SKIP);
> >  }
> >  
> > +/*
> > + * Tell the freezer that the current task should be frozen by it
> > + */
> > +static inline void set_freezable(void)
> > +{
> > +   current->flags &= ~PF_NOFREEZE;
> > +}
> > +
> 
> Given the clearing of the flag above, should we just have a
> set_unfreezeable here that's used above (and potentially elsewhere)...
> (reads more)... or more generic set_[un]freezeable(task_struct *p)
> routines that could also be used in copy_flags below?

Yes, I can introduce set_unfreezeable(), although that would be used in
a couple of places only.

I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
since only current is allowed to set/unset its flags.

> >  #else
> >  static inline int frozen(struct task_struct *p) { return 0; }
> >  static inline int freezing(struct task_struct *p) { return 0; }
> > @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) { 
> >  static inline void freezer_do_not_count(void) {}
> >  static inline void freezer_count(void) {}
> >  static inline int freezer_should_skip(struct task_struct *p) { return 0; }
> > +static inline void set_freezable_current(void) {}

Ah, this is a mistake (wrong name).

> >  #endif
> >  
> >  #endif /* LINUX_FREEZER_H */
> > Index: linux-2.6.22-rc3/kernel/fork.c
> > ===
> > --- linux-2.6.22-rc3.orig/kernel/fork.c
> > +++ linux-2.6.22-rc3/kernel/fork.c
> > @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
> >  {
> > unsigned long new_flags = p->flags;
> >  
> > -   new_flags &= ~(PF_SUPERPRIV | PF_NOFREEZE);
> > +   new_flags &= ~PF_SUPERPRIV;
> > new_flags |= PF_FORKNOEXEC;
> > if (!(clone_flags & CLONE_PTRACE))
> > p->ptrace = 0;
> > Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > ===
> > --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
> > +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
> >  
> > for ( ; ; ) {
> > time_remaining = schedule_timeout_interruptible(time_remaining);
> > -   try_to_freeze();
> > if (time_after(jiffies,
> > prev_balance_time+balanced_irq_interval)) {
> > preempt_disable();
> 
> I'm the one who is confused, aren't I? If I'm reading this right,
> io_apic used to be frozen. After this patch, it will not be frozen. If
> that's the intended behaviour, shouldn't this be two patches - one to
> make kernel threads unfreezeable by default, and one to make threads
> that were formerly freezeable unfreezeable?

Yes, I think you're right.  I tend to try to make too many changes in one
shot. :-)

> 
> [...]
> 
> > Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > ===
> > --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
> > +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > @@ -140,22 +140,6 @@ should be sent to the mailing list avail
> >  website, and not to the Linux Kernel Mailing List. We are working
> >  toward merging suspend2 into the mainline kernel.
> >  
> > -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
> > -I found some kernel threads that don't do it, and they don't freeze
> > -so the system can't sleep. Is this a known behavior?
> > -
> > -A: All such kernel threads need to be fixed, one by one. Select the
> > -place where the thread is safe to be frozen (no kernel semaphores
> > -should be held at that point and it must be safe to sleep there), 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 12:33, Pavel Machek wrote:
> Hi!
> 
> > Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> > ===
> > --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
> > +++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> > @@ -1,13 +1,22 @@
> > -KERNEL THREADS
> > +The Freezer and Kernel Threads
> >  
> > -
> > -Freezer
> > -
> > -Upon entering a suspended state the system will freeze all
> > -tasks. This is done by delivering pseudosignals. This affects
> > -kernel threads, too. To successfully freeze a kernel thread
> > -the thread has to check for the pseudosignal and enter the
> > -refrigerator. Code to do this looks like this:
> > +Before entering a system-wide suspend state as well as before creating a
> > +hibernation snapshot image the system will freeze all tasks, which is done
> > +by delivering fake signals.  This affects kernel threads too, but they 
> > won't be
> > +frozen unless they declare that they want to.  For this purpose
> 
> Well... and unless thread that does disk writes or DMA _wants_ to, you
> have nice disk corruption... It should be pointed out that it is not
> voluntary for those types of threads.

Well, that really depends.

I think the only thing that must not be written to disk is filesystem stuff.
The other things (eg. writing directly to block devices etc.) doesn't hurt us.

Also, I think that DMA-ing while we're creating the image should be impossible
due to devices being frozen at that point.

That said, I think we need to write some better freezer documentation ASAP.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 12:30, Pavel Machek wrote:
> Hi!
> 
> > > This patch is on top of the "Freezer: Avoid freezing kernel threads 
> > > prematurely"
> > > patch that I posted yestarday, available at 
> > > http://lkml.org/lkml/2007/5/25/199
> > > (updated version that applies cleanly on top of 2.6.22-rc3, is available 
> > > at
> > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/07-freezer-avoid-freezing-kernel-threads-prematurely.patch).
> > > It has been tested on a couple of machines and doesn't seem to break 
> > > anything.
> > > 
> > > [As you can see there are quite a lot of files affected, so I didn't add 
> > > all
> > > maintainers of them to the CC list.  In fact, I'm not sure how to handle
> > > notifying them of the change, so please advise.]
> > 
> > Does the lack of comments mean that everyone on the CC list agrees with this
> > approach? ;-)
> > 
> > In the meantime, it turns out that this patch fixes the hibernation/suspend
> > problem with cryptd discussed in the thread at
> > http://lkml.org/lkml/2007/5/26/24 .
> > 
> > The problem is that cryptd doesn't call try_to_freeze() and doesn't set
> > PF_NOFREEZE for itself, so the freezer cannot handle it properly.  In 
> > principle
> > we can add either try_to_freeze() or the setting of PF_NOFREEZE to it, but 
> > if
> > the approach in the $subject patch is acceptable, we'll need to remove that
> > soon.  So, what should we do?
> 
> I'd add PF_NONFREEZE. Changing the defaults in freezer is obviously
> not 2.6.22 material.

OK

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

> Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> ===
> --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
> +++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
> @@ -1,13 +1,22 @@
> -KERNEL THREADS
> +The Freezer and Kernel Threads
>  
> -
> -Freezer
> -
> -Upon entering a suspended state the system will freeze all
> -tasks. This is done by delivering pseudosignals. This affects
> -kernel threads, too. To successfully freeze a kernel thread
> -the thread has to check for the pseudosignal and enter the
> -refrigerator. Code to do this looks like this:
> +Before entering a system-wide suspend state as well as before creating a
> +hibernation snapshot image the system will freeze all tasks, which is done
> +by delivering fake signals.  This affects kernel threads too, but they won't 
> be
> +frozen unless they declare that they want to.  For this purpose

Well... and unless thread that does disk writes or DMA _wants_ to, you
have nice disk corruption... It should be pointed out that it is not
voluntary for those types of threads.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

> > This patch is on top of the "Freezer: Avoid freezing kernel threads 
> > prematurely"
> > patch that I posted yestarday, available at 
> > http://lkml.org/lkml/2007/5/25/199
> > (updated version that applies cleanly on top of 2.6.22-rc3, is available at
> > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/07-freezer-avoid-freezing-kernel-threads-prematurely.patch).
> > It has been tested on a couple of machines and doesn't seem to break 
> > anything.
> > 
> > [As you can see there are quite a lot of files affected, so I didn't add all
> > maintainers of them to the CC list.  In fact, I'm not sure how to handle
> > notifying them of the change, so please advise.]
> 
> Does the lack of comments mean that everyone on the CC list agrees with this
> approach? ;-)
> 
> In the meantime, it turns out that this patch fixes the hibernation/suspend
> problem with cryptd discussed in the thread at
> http://lkml.org/lkml/2007/5/26/24 .
> 
> The problem is that cryptd doesn't call try_to_freeze() and doesn't set
> PF_NOFREEZE for itself, so the freezer cannot handle it properly.  In 
> principle
> we can add either try_to_freeze() or the setting of PF_NOFREEZE to it, but if
> the approach in the $subject patch is acceptable, we'll need to remove that
> soon.  So, what should we do?

I'd add PF_NONFREEZE. Changing the defaults in freezer is obviously
not 2.6.22 material.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hello!

In reply to your more recent message, I had looked but not tried, so
didn't feel in a position to reply yet.

On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
>  63 files changed, 78 insertions(+), 138 deletions(-)

Well, that looks good, for a start :)

> Index: linux-2.6.22-rc3/kernel/exit.c
> ===
> --- linux-2.6.22-rc3.orig/kernel/exit.c
> +++ linux-2.6.22-rc3/kernel/exit.c
> @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
>* they would be locked into memory.
>*/
>   exit_mm(current);
> + /*
> +  * We don't want to have TIF_FREEZE set if the system-wide hibernation
> +  * or suspend transision begins right now.
> +  */
> + current->flags |= PF_NOFREEZE;

s/transision/transition
 
>   set_special_pids(1, 1);
>   proc_clear_tty(current);
> Index: linux-2.6.22-rc3/include/linux/freezer.h
> ===
> --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> +++ linux-2.6.22-rc3/include/linux/freezer.h
> @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
>   return !!(p->flags & PF_FREEZER_SKIP);
>  }
>  
> +/*
> + * Tell the freezer that the current task should be frozen by it
> + */
> +static inline void set_freezable(void)
> +{
> + current->flags &= ~PF_NOFREEZE;
> +}
> +

Given the clearing of the flag above, should we just have a
set_unfreezeable here that's used above (and potentially elsewhere)...
(reads more)... or more generic set_[un]freezeable(task_struct *p)
routines that could also be used in copy_flags below?

>  #else
>  static inline int frozen(struct task_struct *p) { return 0; }
>  static inline int freezing(struct task_struct *p) { return 0; }
> @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) { 
>  static inline void freezer_do_not_count(void) {}
>  static inline void freezer_count(void) {}
>  static inline int freezer_should_skip(struct task_struct *p) { return 0; }
> +static inline void set_freezable_current(void) {}
>  #endif
>  
>  #endif /* LINUX_FREEZER_H */
> Index: linux-2.6.22-rc3/kernel/fork.c
> ===
> --- linux-2.6.22-rc3.orig/kernel/fork.c
> +++ linux-2.6.22-rc3/kernel/fork.c
> @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
>  {
>   unsigned long new_flags = p->flags;
>  
> - new_flags &= ~(PF_SUPERPRIV | PF_NOFREEZE);
> + new_flags &= ~PF_SUPERPRIV;
>   new_flags |= PF_FORKNOEXEC;
>   if (!(clone_flags & CLONE_PTRACE))
>   p->ptrace = 0;
> Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> ===
> --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
> +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
>  
>   for ( ; ; ) {
>   time_remaining = schedule_timeout_interruptible(time_remaining);
> - try_to_freeze();
>   if (time_after(jiffies,
>   prev_balance_time+balanced_irq_interval)) {
>   preempt_disable();

I'm the one who is confused, aren't I? If I'm reading this right,
io_apic used to be frozen. After this patch, it will not be frozen. If
that's the intended behaviour, shouldn't this be two patches - one to
make kernel threads unfreezeable by default, and one to make threads
that were formerly freezeable unfreezeable?

[...]

> Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
> ===
> --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
> +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
> @@ -140,22 +140,6 @@ should be sent to the mailing list avail
>  website, and not to the Linux Kernel Mailing List. We are working
>  toward merging suspend2 into the mainline kernel.
>  
> -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
> -I found some kernel threads that don't do it, and they don't freeze
> -so the system can't sleep. Is this a known behavior?
> -
> -A: All such kernel threads need to be fixed, one by one. Select the
> -place where the thread is safe to be frozen (no kernel semaphores
> -should be held at that point and it must be safe to sleep there), and
> -add:
> -
> -   try_to_freeze();
> -
> -If the thread is needed for writing the image to storage, you should
> -instead set the PF_NOFREEZE process flag when creating the thread (and
> -be very careful).
> -
> -
>  Q: What is the difference between "platform" and "shutdown"?
>  
>  A:

Perhaps it would be good to keep a variant of this question, along the
lines of:

Q: I have a kernel thread that needs to be frozen during hibernation.
How do I make that happen?

Regards,

Nigel


signature.asc
Description: This is a digitally signed message part

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Sunday, 27 May 2007 00:12, Rafael J. Wysocki wrote:
> Hi,
> 
> Following the "Freezing of kernel threads" discussion
> (http://lkml.org/lkml/2007/5/12/162) I have created a patch that changes the
> freezer's behavior with respect to kernel threads.  Namely, with the patch
> applied all kernel threads are nonfreezable by default (have PF_NOFREEZE set)
> and the ones that want to be frozen need to call set_freezable() (which clears
> PF_NOFREEZE for them) and try_to_freeze().  The other (nonfreezable) kernel
> threads don't need to call try_to_freeze() any more.
> 
> I have removed try_to_freeze() from a handful of kernel threads that I think
> need not be freezable, but in many cases I wasn't quite sure whether or not
> it was a good idea to change the current behavior.  For this reason I've added
> set_freezable() to the majority of (currently freezable) kernel threads that
> belong to device drivers and filesystems.
> 
> Of course, I have removed the setting of PF_NOFREEZE from the kernel threads
> that are currently nonfreezable, since with the other changes in the patch it
> isn't necessary any more.
> 
> This patch is on top of the "Freezer: Avoid freezing kernel threads 
> prematurely"
> patch that I posted yestarday, available at http://lkml.org/lkml/2007/5/25/199
> (updated version that applies cleanly on top of 2.6.22-rc3, is available at
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/07-freezer-avoid-freezing-kernel-threads-prematurely.patch).
> It has been tested on a couple of machines and doesn't seem to break anything.
> 
> [As you can see there are quite a lot of files affected, so I didn't add all
> maintainers of them to the CC list.  In fact, I'm not sure how to handle
> notifying them of the change, so please advise.]

Does the lack of comments mean that everyone on the CC list agrees with this
approach? ;-)

In the meantime, it turns out that this patch fixes the hibernation/suspend
problem with cryptd discussed in the thread at
http://lkml.org/lkml/2007/5/26/24 .

The problem is that cryptd doesn't call try_to_freeze() and doesn't set
PF_NOFREEZE for itself, so the freezer cannot handle it properly.  In principle
we can add either try_to_freeze() or the setting of PF_NOFREEZE to it, but if
the approach in the $subject patch is acceptable, we'll need to remove that
soon.  So, what should we do?

Rafael

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Sunday, 27 May 2007 00:12, Rafael J. Wysocki wrote:
 Hi,
 
 Following the Freezing of kernel threads discussion
 (http://lkml.org/lkml/2007/5/12/162) I have created a patch that changes the
 freezer's behavior with respect to kernel threads.  Namely, with the patch
 applied all kernel threads are nonfreezable by default (have PF_NOFREEZE set)
 and the ones that want to be frozen need to call set_freezable() (which clears
 PF_NOFREEZE for them) and try_to_freeze().  The other (nonfreezable) kernel
 threads don't need to call try_to_freeze() any more.
 
 I have removed try_to_freeze() from a handful of kernel threads that I think
 need not be freezable, but in many cases I wasn't quite sure whether or not
 it was a good idea to change the current behavior.  For this reason I've added
 set_freezable() to the majority of (currently freezable) kernel threads that
 belong to device drivers and filesystems.
 
 Of course, I have removed the setting of PF_NOFREEZE from the kernel threads
 that are currently nonfreezable, since with the other changes in the patch it
 isn't necessary any more.
 
 This patch is on top of the Freezer: Avoid freezing kernel threads 
 prematurely
 patch that I posted yestarday, available at http://lkml.org/lkml/2007/5/25/199
 (updated version that applies cleanly on top of 2.6.22-rc3, is available at
 http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/07-freezer-avoid-freezing-kernel-threads-prematurely.patch).
 It has been tested on a couple of machines and doesn't seem to break anything.
 
 [As you can see there are quite a lot of files affected, so I didn't add all
 maintainers of them to the CC list.  In fact, I'm not sure how to handle
 notifying them of the change, so please advise.]

Does the lack of comments mean that everyone on the CC list agrees with this
approach? ;-)

In the meantime, it turns out that this patch fixes the hibernation/suspend
problem with cryptd discussed in the thread at
http://lkml.org/lkml/2007/5/26/24 .

The problem is that cryptd doesn't call try_to_freeze() and doesn't set
PF_NOFREEZE for itself, so the freezer cannot handle it properly.  In principle
we can add either try_to_freeze() or the setting of PF_NOFREEZE to it, but if
the approach in the $subject patch is acceptable, we'll need to remove that
soon.  So, what should we do?

Rafael

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hello!

In reply to your more recent message, I had looked but not tried, so
didn't feel in a position to reply yet.

On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
  63 files changed, 78 insertions(+), 138 deletions(-)

Well, that looks good, for a start :)

 Index: linux-2.6.22-rc3/kernel/exit.c
 ===
 --- linux-2.6.22-rc3.orig/kernel/exit.c
 +++ linux-2.6.22-rc3/kernel/exit.c
 @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
* they would be locked into memory.
*/
   exit_mm(current);
 + /*
 +  * We don't want to have TIF_FREEZE set if the system-wide hibernation
 +  * or suspend transision begins right now.
 +  */
 + current-flags |= PF_NOFREEZE;

s/transision/transition
 
   set_special_pids(1, 1);
   proc_clear_tty(current);
 Index: linux-2.6.22-rc3/include/linux/freezer.h
 ===
 --- linux-2.6.22-rc3.orig/include/linux/freezer.h
 +++ linux-2.6.22-rc3/include/linux/freezer.h
 @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
   return !!(p-flags  PF_FREEZER_SKIP);
  }
  
 +/*
 + * Tell the freezer that the current task should be frozen by it
 + */
 +static inline void set_freezable(void)
 +{
 + current-flags = ~PF_NOFREEZE;
 +}
 +

Given the clearing of the flag above, should we just have a
set_unfreezeable here that's used above (and potentially elsewhere)...
(reads more)... or more generic set_[un]freezeable(task_struct *p)
routines that could also be used in copy_flags below?

  #else
  static inline int frozen(struct task_struct *p) { return 0; }
  static inline int freezing(struct task_struct *p) { return 0; }
 @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) { 
  static inline void freezer_do_not_count(void) {}
  static inline void freezer_count(void) {}
  static inline int freezer_should_skip(struct task_struct *p) { return 0; }
 +static inline void set_freezable_current(void) {}
  #endif
  
  #endif /* LINUX_FREEZER_H */
 Index: linux-2.6.22-rc3/kernel/fork.c
 ===
 --- linux-2.6.22-rc3.orig/kernel/fork.c
 +++ linux-2.6.22-rc3/kernel/fork.c
 @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
  {
   unsigned long new_flags = p-flags;
  
 - new_flags = ~(PF_SUPERPRIV | PF_NOFREEZE);
 + new_flags = ~PF_SUPERPRIV;
   new_flags |= PF_FORKNOEXEC;
   if (!(clone_flags  CLONE_PTRACE))
   p-ptrace = 0;
 Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
 ===
 --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
 +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
 @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
  
   for ( ; ; ) {
   time_remaining = schedule_timeout_interruptible(time_remaining);
 - try_to_freeze();
   if (time_after(jiffies,
   prev_balance_time+balanced_irq_interval)) {
   preempt_disable();

I'm the one who is confused, aren't I? If I'm reading this right,
io_apic used to be frozen. After this patch, it will not be frozen. If
that's the intended behaviour, shouldn't this be two patches - one to
make kernel threads unfreezeable by default, and one to make threads
that were formerly freezeable unfreezeable?

[...]

 Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
 ===
 --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
 +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
 @@ -140,22 +140,6 @@ should be sent to the mailing list avail
  website, and not to the Linux Kernel Mailing List. We are working
  toward merging suspend2 into the mainline kernel.
  
 -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
 -I found some kernel threads that don't do it, and they don't freeze
 -so the system can't sleep. Is this a known behavior?
 -
 -A: All such kernel threads need to be fixed, one by one. Select the
 -place where the thread is safe to be frozen (no kernel semaphores
 -should be held at that point and it must be safe to sleep there), and
 -add:
 -
 -   try_to_freeze();
 -
 -If the thread is needed for writing the image to storage, you should
 -instead set the PF_NOFREEZE process flag when creating the thread (and
 -be very careful).
 -
 -
  Q: What is the difference between platform and shutdown?
  
  A:

Perhaps it would be good to keep a variant of this question, along the
lines of:

Q: I have a kernel thread that needs to be frozen during hibernation.
How do I make that happen?

Regards,

Nigel


signature.asc
Description: This is a digitally signed message part

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

  This patch is on top of the Freezer: Avoid freezing kernel threads 
  prematurely
  patch that I posted yestarday, available at 
  http://lkml.org/lkml/2007/5/25/199
  (updated version that applies cleanly on top of 2.6.22-rc3, is available at
  http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/07-freezer-avoid-freezing-kernel-threads-prematurely.patch).
  It has been tested on a couple of machines and doesn't seem to break 
  anything.
  
  [As you can see there are quite a lot of files affected, so I didn't add all
  maintainers of them to the CC list.  In fact, I'm not sure how to handle
  notifying them of the change, so please advise.]
 
 Does the lack of comments mean that everyone on the CC list agrees with this
 approach? ;-)
 
 In the meantime, it turns out that this patch fixes the hibernation/suspend
 problem with cryptd discussed in the thread at
 http://lkml.org/lkml/2007/5/26/24 .
 
 The problem is that cryptd doesn't call try_to_freeze() and doesn't set
 PF_NOFREEZE for itself, so the freezer cannot handle it properly.  In 
 principle
 we can add either try_to_freeze() or the setting of PF_NOFREEZE to it, but if
 the approach in the $subject patch is acceptable, we'll need to remove that
 soon.  So, what should we do?

I'd add PF_NONFREEZE. Changing the defaults in freezer is obviously
not 2.6.22 material.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Pavel Machek]

Hi!

 Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
 ===
 --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
 +++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
 @@ -1,13 +1,22 @@
 -KERNEL THREADS
 +The Freezer and Kernel Threads
  
 -
 -Freezer
 -
 -Upon entering a suspended state the system will freeze all
 -tasks. This is done by delivering pseudosignals. This affects
 -kernel threads, too. To successfully freeze a kernel thread
 -the thread has to check for the pseudosignal and enter the
 -refrigerator. Code to do this looks like this:
 +Before entering a system-wide suspend state as well as before creating a
 +hibernation snapshot image the system will freeze all tasks, which is done
 +by delivering fake signals.  This affects kernel threads too, but they won't 
 be
 +frozen unless they declare that they want to.  For this purpose

Well... and unless thread that does disk writes or DMA _wants_ to, you
have nice disk corruption... It should be pointed out that it is not
voluntary for those types of threads.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 12:30, Pavel Machek wrote:
 Hi!
 
   This patch is on top of the Freezer: Avoid freezing kernel threads 
   prematurely
   patch that I posted yestarday, available at 
   http://lkml.org/lkml/2007/5/25/199
   (updated version that applies cleanly on top of 2.6.22-rc3, is available 
   at
   http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/07-freezer-avoid-freezing-kernel-threads-prematurely.patch).
   It has been tested on a couple of machines and doesn't seem to break 
   anything.
   
   [As you can see there are quite a lot of files affected, so I didn't add 
   all
   maintainers of them to the CC list.  In fact, I'm not sure how to handle
   notifying them of the change, so please advise.]
  
  Does the lack of comments mean that everyone on the CC list agrees with this
  approach? ;-)
  
  In the meantime, it turns out that this patch fixes the hibernation/suspend
  problem with cryptd discussed in the thread at
  http://lkml.org/lkml/2007/5/26/24 .
  
  The problem is that cryptd doesn't call try_to_freeze() and doesn't set
  PF_NOFREEZE for itself, so the freezer cannot handle it properly.  In 
  principle
  we can add either try_to_freeze() or the setting of PF_NOFREEZE to it, but 
  if
  the approach in the $subject patch is acceptable, we'll need to remove that
  soon.  So, what should we do?
 
 I'd add PF_NONFREEZE. Changing the defaults in freezer is obviously
 not 2.6.22 material.

OK

Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 12:33, Pavel Machek wrote:
 Hi!
 
  Index: linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
  ===
  --- linux-2.6.22-rc3.orig/Documentation/power/kernel_threads.txt
  +++ linux-2.6.22-rc3/Documentation/power/kernel_threads.txt
  @@ -1,13 +1,22 @@
  -KERNEL THREADS
  +The Freezer and Kernel Threads
   
  -
  -Freezer
  -
  -Upon entering a suspended state the system will freeze all
  -tasks. This is done by delivering pseudosignals. This affects
  -kernel threads, too. To successfully freeze a kernel thread
  -the thread has to check for the pseudosignal and enter the
  -refrigerator. Code to do this looks like this:
  +Before entering a system-wide suspend state as well as before creating a
  +hibernation snapshot image the system will freeze all tasks, which is done
  +by delivering fake signals.  This affects kernel threads too, but they 
  won't be
  +frozen unless they declare that they want to.  For this purpose
 
 Well... and unless thread that does disk writes or DMA _wants_ to, you
 have nice disk corruption... It should be pointed out that it is not
 voluntary for those types of threads.

Well, that really depends.

I think the only thing that must not be written to disk is filesystem stuff.
The other things (eg. writing directly to block devices etc.) doesn't hurt us.

Also, I think that DMA-ing while we're creating the image should be impossible
due to devices being frozen at that point.

That said, I think we need to write some better freezer documentation ASAP.

Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
 Hello!
 
 In reply to your more recent message, I had looked but not tried, so
 didn't feel in a position to reply yet.
 
 On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
   63 files changed, 78 insertions(+), 138 deletions(-)
 
 Well, that looks good, for a start :)
 
  Index: linux-2.6.22-rc3/kernel/exit.c
  ===
  --- linux-2.6.22-rc3.orig/kernel/exit.c
  +++ linux-2.6.22-rc3/kernel/exit.c
  @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
   * they would be locked into memory.
   */
  exit_mm(current);
  +   /*
  +* We don't want to have TIF_FREEZE set if the system-wide hibernation
  +* or suspend transision begins right now.
  +*/
  +   current-flags |= PF_NOFREEZE;
 
 s/transision/transition

Thanks, will fix.

  set_special_pids(1, 1);
  proc_clear_tty(current);
  Index: linux-2.6.22-rc3/include/linux/freezer.h
  ===
  --- linux-2.6.22-rc3.orig/include/linux/freezer.h
  +++ linux-2.6.22-rc3/include/linux/freezer.h
  @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
  return !!(p-flags  PF_FREEZER_SKIP);
   }
   
  +/*
  + * Tell the freezer that the current task should be frozen by it
  + */
  +static inline void set_freezable(void)
  +{
  +   current-flags = ~PF_NOFREEZE;
  +}
  +
 
 Given the clearing of the flag above, should we just have a
 set_unfreezeable here that's used above (and potentially elsewhere)...
 (reads more)... or more generic set_[un]freezeable(task_struct *p)
 routines that could also be used in copy_flags below?

Yes, I can introduce set_unfreezeable(), although that would be used in
a couple of places only.

I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
since only current is allowed to set/unset its flags.

   #else
   static inline int frozen(struct task_struct *p) { return 0; }
   static inline int freezing(struct task_struct *p) { return 0; }
  @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) { 
   static inline void freezer_do_not_count(void) {}
   static inline void freezer_count(void) {}
   static inline int freezer_should_skip(struct task_struct *p) { return 0; }
  +static inline void set_freezable_current(void) {}

Ah, this is a mistake (wrong name).

   #endif
   
   #endif /* LINUX_FREEZER_H */
  Index: linux-2.6.22-rc3/kernel/fork.c
  ===
  --- linux-2.6.22-rc3.orig/kernel/fork.c
  +++ linux-2.6.22-rc3/kernel/fork.c
  @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
   {
  unsigned long new_flags = p-flags;
   
  -   new_flags = ~(PF_SUPERPRIV | PF_NOFREEZE);
  +   new_flags = ~PF_SUPERPRIV;
  new_flags |= PF_FORKNOEXEC;
  if (!(clone_flags  CLONE_PTRACE))
  p-ptrace = 0;
  Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
  ===
  --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
  +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
  @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
   
  for ( ; ; ) {
  time_remaining = schedule_timeout_interruptible(time_remaining);
  -   try_to_freeze();
  if (time_after(jiffies,
  prev_balance_time+balanced_irq_interval)) {
  preempt_disable();
 
 I'm the one who is confused, aren't I? If I'm reading this right,
 io_apic used to be frozen. After this patch, it will not be frozen. If
 that's the intended behaviour, shouldn't this be two patches - one to
 make kernel threads unfreezeable by default, and one to make threads
 that were formerly freezeable unfreezeable?

Yes, I think you're right.  I tend to try to make too many changes in one
shot. :-)

 
 [...]
 
  Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
  ===
  --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
  +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
  @@ -140,22 +140,6 @@ should be sent to the mailing list avail
   website, and not to the Linux Kernel Mailing List. We are working
   toward merging suspend2 into the mainline kernel.
   
  -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
  -I found some kernel threads that don't do it, and they don't freeze
  -so the system can't sleep. Is this a known behavior?
  -
  -A: All such kernel threads need to be fixed, one by one. Select the
  -place where the thread is safe to be frozen (no kernel semaphores
  -should be held at that point and it must be safe to sleep there), and
  -add:
  -
  -   try_to_freeze();
  -
  -If the thread is needed for writing the image to storage, you should
  -instead set the PF_NOFREEZE process flag when creating the thread (and
  -be very 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
 On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
  Hello!
  
  In reply to your more recent message, I had looked but not tried, so
  didn't feel in a position to reply yet.
  
  On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
63 files changed, 78 insertions(+), 138 deletions(-)
  
  Well, that looks good, for a start :)
  
   Index: linux-2.6.22-rc3/kernel/exit.c
   ===
   --- linux-2.6.22-rc3.orig/kernel/exit.c
   +++ linux-2.6.22-rc3/kernel/exit.c
   @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
  * they would be locked into memory.
  */
 exit_mm(current);
   + /*
   +  * We don't want to have TIF_FREEZE set if the system-wide hibernation
   +  * or suspend transision begins right now.
   +  */
   + current-flags |= PF_NOFREEZE;
  
  s/transision/transition
 
 Thanks, will fix.
 
 set_special_pids(1, 1);
 proc_clear_tty(current);
   Index: linux-2.6.22-rc3/include/linux/freezer.h
   ===
   --- linux-2.6.22-rc3.orig/include/linux/freezer.h
   +++ linux-2.6.22-rc3/include/linux/freezer.h
   @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
 return !!(p-flags  PF_FREEZER_SKIP);
}

   +/*
   + * Tell the freezer that the current task should be frozen by it
   + */
   +static inline void set_freezable(void)
   +{
   + current-flags = ~PF_NOFREEZE;
   +}
   +
  
  Given the clearing of the flag above, should we just have a
  set_unfreezeable here that's used above (and potentially elsewhere)...
  (reads more)... or more generic set_[un]freezeable(task_struct *p)
  routines that could also be used in copy_flags below?
 
 Yes, I can introduce set_unfreezeable(), although that would be used in
 a couple of places only.
 
 I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
 since only current is allowed to set/unset its flags.

The copy_flags routine changes another process's flags - that's why I
was suggesting this.

#else
static inline int frozen(struct task_struct *p) { return 0; }
static inline int freezing(struct task_struct *p) { return 0; }
   @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) { 
static inline void freezer_do_not_count(void) {}
static inline void freezer_count(void) {}
static inline int freezer_should_skip(struct task_struct *p) { return 0; 
   }
   +static inline void set_freezable_current(void) {}
 
 Ah, this is a mistake (wrong name).
 
#endif

#endif /* LINUX_FREEZER_H */
   Index: linux-2.6.22-rc3/kernel/fork.c
   ===
   --- linux-2.6.22-rc3.orig/kernel/fork.c
   +++ linux-2.6.22-rc3/kernel/fork.c
   @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
{
 unsigned long new_flags = p-flags;

   - new_flags = ~(PF_SUPERPRIV | PF_NOFREEZE);
   + new_flags = ~PF_SUPERPRIV;
 new_flags |= PF_FORKNOEXEC;
 if (!(clone_flags  CLONE_PTRACE))
 p-ptrace = 0;
   Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
   ===
   --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
   +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
   @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)

 for ( ; ; ) {
 time_remaining = schedule_timeout_interruptible(time_remaining);
   - try_to_freeze();
 if (time_after(jiffies,
 prev_balance_time+balanced_irq_interval)) {
 preempt_disable();
  
  I'm the one who is confused, aren't I? If I'm reading this right,
  io_apic used to be frozen. After this patch, it will not be frozen. If
  that's the intended behaviour, shouldn't this be two patches - one to
  make kernel threads unfreezeable by default, and one to make threads
  that were formerly freezeable unfreezeable?
 
 Yes, I think you're right.  I tend to try to make too many changes in one
 shot. :-)
 
  
  [...]
  
   Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
   ===
   --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
   +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
   @@ -140,22 +140,6 @@ should be sent to the mailing list avail
website, and not to the Linux Kernel Mailing List. We are working
toward merging suspend2 into the mainline kernel.

   -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
   -I found some kernel threads that don't do it, and they don't freeze
   -so the system can't sleep. Is this a known behavior?
   -
   -A: All such kernel threads need to be fixed, one by one. Select the
   -place where the thread is safe to be frozen (no kernel semaphores
   -should be held at that point 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Rafael J. Wysocki]

On Monday, 28 May 2007 23:26, Nigel Cunningham wrote:
 Hi.
 
 On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
  On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
   Hello!
   
   In reply to your more recent message, I had looked but not tried, so
   didn't feel in a position to reply yet.
   
   On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
 63 files changed, 78 insertions(+), 138 deletions(-)
   
   Well, that looks good, for a start :)
   
Index: linux-2.6.22-rc3/kernel/exit.c
===
--- linux-2.6.22-rc3.orig/kernel/exit.c
+++ linux-2.6.22-rc3/kernel/exit.c
@@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
 * they would be locked into memory.
 */
exit_mm(current);
+   /*
+* We don't want to have TIF_FREEZE set if the system-wide 
hibernation
+* or suspend transision begins right now.
+*/
+   current-flags |= PF_NOFREEZE;
   
   s/transision/transition
  
  Thanks, will fix.
  
set_special_pids(1, 1);
proc_clear_tty(current);
Index: linux-2.6.22-rc3/include/linux/freezer.h
===
--- linux-2.6.22-rc3.orig/include/linux/freezer.h
+++ linux-2.6.22-rc3/include/linux/freezer.h
@@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
return !!(p-flags  PF_FREEZER_SKIP);
 }
 
+/*
+ * Tell the freezer that the current task should be frozen by it
+ */
+static inline void set_freezable(void)
+{
+   current-flags = ~PF_NOFREEZE;
+}
+
   
   Given the clearing of the flag above, should we just have a
   set_unfreezeable here that's used above (and potentially elsewhere)...
   (reads more)... or more generic set_[un]freezeable(task_struct *p)
   routines that could also be used in copy_flags below?
  
  Yes, I can introduce set_unfreezeable(), although that would be used in
  a couple of places only.
  
  I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
  since only current is allowed to set/unset its flags.
 
 The copy_flags routine changes another process's flags - that's why I
 was suggesting this.

Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there,
not adding anything new. :-)

Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

[Nigel Cunningham]

Hi.

On Tue, 2007-05-29 at 00:51 +0200, Rafael J. Wysocki wrote:
  The copy_flags routine changes another process's flags - that's why
 I
  was suggesting this.
 
 Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there,
 not adding anything new. :-)

Doh! Sorry :)

Nigel


signature.asc
Description: This is a digitally signed message part