kthread, signals and PF_FREEZE (suspend)

kthread, signals and PF_FREEZE (suspend)

[Christophe Saout]

Hi,

I was wondering, has kthread been tested with the suspend code?

When trying to freeze the processes the suspend code sets PF_FREEZE on a
process and calls signal_wake_up(p, 0);

That means that signal_pending() will return true for that process which
will make kthread stop the thread.

The workqueues have PF_IOTHREAD set and I'm only seeing those on my
machine that's why it doesn't fail.

But the migration threads for example call signal_pending() directly
after schedule() before checking PF_FREEZE and calling refrigerator()
(which BTW flushes all signals).

Re: kthread, signals and PF_FREEZE (suspend)

[Rusty Russell]

In message <1076890731.5525.31.camel@leto.cs.pocnet.net> you write:
> Hi,
> 
> I was wondering, has kthread been tested with the suspend code?

No, it hasn't.

> When trying to freeze the processes the suspend code sets PF_FREEZE on a
> process and calls signal_wake_up(p, 0);
> 
> 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.

> The workqueues have PF_IOTHREAD set and I'm only seeing those on my
> machine that's why it doesn't fail.
> 
> But the migration threads for example call signal_pending() directly
> after schedule() before checking PF_FREEZE and calling refrigerator()
> (which BTW flushes all signals).

This will only happen on SMP systems with > 1 cpu though?  I don't
think suspend works there anyway.

However, ksoftirqd will die I think: that will hurt if lots of irqs
come in.

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

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: kthread, signals and PF_FREEZE (suspend)

[Pavel Machek]

Hi!

> > The workqueues have PF_IOTHREAD set and I'm only seeing those on my
> > machine that's why it doesn't fail.
> > 
> > But the migration threads for example call signal_pending() directly
> > after schedule() before checking PF_FREEZE and calling refrigerator()
> > (which BTW flushes all signals).
> 
> This will only happen on SMP systems with > 1 cpu though?  I don't
> think suspend works there anyway.
> 
> However, ksoftirqd will die I think: that will hurt if lots of irqs
> come in.
> 
> Pavel, what is the answer here?  Should the refrigerator code be in
> the kthread infrastructure?  Why does the workqueue code set
> PF_IOTHREAD?

I assumed that workqueues may be needed for harddisks to
function... If that's the case, it can't be simply stopped. 
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: kthread, signals and PF_FREEZE (suspend)

[Christophe Saout]

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?

Re: kthread, signals and PF_FREEZE (suspend)

[Jamie Lokier]

Rusty Russell wrote:
> > 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.

Yowch.  Does suspend mean this warning in futex_wait is wrong?

	/* A spurious wakeup should never happen. */
	WARN_ON(!signal_pending(current));
	return -EINTR;

-- Jamie

Re: kthread, signals and PF_FREEZE (suspend)

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Jamie Lokier um 17:53:

> Rusty Russell wrote:
> > > 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.
> 
> Yowch.  Does suspend mean this warning in futex_wait is wrong?
> 
> 	/* A spurious wakeup should never happen. */
> 	WARN_ON(!signal_pending(current));
> 	return -EINTR;

I just tried it on my notebook. It works, no warning.

I don't know how things work exactly. There is some stuff in the arch
signal.c in do_signal that also handles PF_FREEZE.

Re: kthread, signals and PF_FREEZE (suspend)

[Rusty Russell]

In message <20040216165329.GB17323@mail.shareable.org> you write:
> Rusty Russell wrote:
> > > 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.
> 
> Yowch.  Does suspend mean this warning in futex_wait is wrong?
> 
> 	/* A spurious wakeup should never happen. */
> 	WARN_ON(!signal_pending(current));
> 	return -EINTR;

That's why it's a WARN_ON not a BUG_ON, and why suspend is
experimental.  But the bug reports we've seen didn't mention "I was
suspending when..."

Although Dirk has CONFIG_SOFTWARE_SUSPEND=y.

Cheers,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.