On Sunday, 27 May 2007 00:12, Rafael J. Wysocki wrote:
> 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
> 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
In the meantime, it turns out that this patch fixes the hibernation/suspend
problem with cryptd discussed in the thread at
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?
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/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]