Re: kthread, signals and PF_FREEZE (suspend)

[Christophe Saout <christophe@saout.de>]

Am Mo, den 16.02.2004 schrieb Rusty Russell um 04:38:

> > That means that signal_pending() will return true for that process which
> > will make kthread stop the thread.
> 
> Yes, the way they are currently coded.  I had assumed that spurious
> signals do not occur.

Yes, the freeze signalling is somewhat hackish. It sets the PF_FREEZE
flag and calls signal_wake_up on the process.

> Pavel, what is the answer here?  Should the refrigerator code be in
> the kthread infrastructure?  Why does the workqueue code set
> PF_IOTHREAD?

If PF_IOTHREAD is set the suspend code won't try to freeze the process
(kthread works here with the suspend code).

But you could change

while (!signal_pending(current))
        ret = threadfn(data);

to

for (;;) {
	if (current->flags & PF_FREEZE)
		refrigerator(PF_IOTHREAD);
	if (signal_pending())
		break;
        ret = threadfn(data);
}

or something like that.

The threadfn will return when it sees a signal. If it was a "PF_FREEZE
signal" the refrigerator will suspend the code and flush the signal. The
threadfn will be reentered afterwards (it should be prepared for this to
happen if it doesn't handle PF_FREEZE itself).

If it was real signal the thread will exit.

BTW: You might want to export the kthread functions:

EXPORT_SYMBOL(kthread_create);
EXPORT_SYMBOL(kthread_bind);
EXPORT_SYMBOL(kthread_stop);

Should I send a patch to Andrew?