which signal is sent to freeze process?

which signal is sent to freeze process?

[Agarwal, Lomesh]

My understanding is that Linux kernel sends a signal to freeze processes
during suspend2ram operation. Which signal is used to achieve this?
The problem I am facing is that some of the system calls are failing
with EINTR errno during suspend operation and I want to install a signal
handler for freeze signal with SA_RESTART flag. That should make the
kernel to retry the system calls. Right?

Thanks,
Lomesh

Re: which signal is sent to freeze process?

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

Hi.

On Thursday 19 July 2007 09:42:02 Agarwal, Lomesh wrote:
> My understanding is that Linux kernel sends a signal to freeze processes
> during suspend2ram operation. Which signal is used to achieve this?
> The problem I am facing is that some of the system calls are failing
> with EINTR errno during suspend operation and I want to install a signal
> handler for freeze signal with SA_RESTART flag. That should make the
> kernel to retry the system calls. Right?

No signal is sent. We tell affected processes that they have a signal pending, 
and capture them in the signal handling code while the suspend to ram is 
occuring. After the suspend to ram is finished, we recalculate whether they 
have a signal pending, and let them continue.

Not being a guru on signal handling itself, I won't try to answer the question 
itself :\.

Regards,

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

Can you point me to code where kernel captures process in signal
handling and code which runs after suspend to ram is finished?

-----Original Message-----
From: Nigel Cunningham [mailto:nigel@nigel.suspend2.net] 
Sent: Wednesday, July 18, 2007 7:19 PM
To: Agarwal, Lomesh
Cc: linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?

Hi.

On Thursday 19 July 2007 09:42:02 Agarwal, Lomesh wrote:
> My understanding is that Linux kernel sends a signal to freeze
processes
> during suspend2ram operation. Which signal is used to achieve this?
> The problem I am facing is that some of the system calls are failing
> with EINTR errno during suspend operation and I want to install a
signal
> handler for freeze signal with SA_RESTART flag. That should make the
> kernel to retry the system calls. Right?

No signal is sent. We tell affected processes that they have a signal
pending, 
and capture them in the signal handling code while the suspend to ram is

occuring. After the suspend to ram is finished, we recalculate whether
they 
have a signal pending, and let them continue.

Not being a guru on signal handling itself, I won't try to answer the
question 
itself :\.

Regards,

Nigel

Re: which signal is sent to freeze process?

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Hi.

On Thursday 19 July 2007 14:09:56 Agarwal, Lomesh wrote:
> Can you point me to code where kernel captures process in signal
> handling and code which runs after suspend to ram is finished?

Sure.

It's in kernel/signal.c (get_signal_to_deliver) for x86 and x86_64, and 
arch/<name>/kernel/signal.c for other arches. The support for other arches is 
the place x86 & x86_64 used to use - I wonder if they should be going away 
(Rafael cc'd to raise this point with him).

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

So basically I can not install a signal handler to catch freeze signal
in the process. Right?
Is there any other way to solve the problem I am facing? After resume
some of the system calls are failing in some of my applications with
errno set as EINTR. I wanted to explore a way to not check for this
error all over the place and somehow retry failed system call. Any
ideas?

-----Original Message-----
From: Nigel Cunningham [mailto:nigel@nigel.suspend2.net] 
Sent: Wednesday, July 18, 2007 9:59 PM
To: Agarwal, Lomesh; Rafael Wysocki
Cc: linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?

Hi.

On Thursday 19 July 2007 14:09:56 Agarwal, Lomesh wrote:
> Can you point me to code where kernel captures process in signal
> handling and code which runs after suspend to ram is finished?

Sure.

It's in kernel/signal.c (get_signal_to_deliver) for x86 and x86_64, and 
arch/<name>/kernel/signal.c for other arches. The support for other
arches is 
the place x86 & x86_64 used to use - I wonder if they should be going
away 
(Rafael cc'd to raise this point with him).

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Thursday, 19 July 2007 23:06, Agarwal, Lomesh wrote:
> So basically I can not install a signal handler to catch freeze signal
> in the process. Right?
> Is there any other way to solve the problem I am facing? After resume
> some of the system calls are failing in some of my applications with
> errno set as EINTR. I wanted to explore a way to not check for this
> error all over the place and somehow retry failed system call. Any
> ideas?

Can you please tell us what exactly these applications do?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Thursday, 19 July 2007 06:59, Nigel Cunningham wrote:
> Hi.
> 
> On Thursday 19 July 2007 14:09:56 Agarwal, Lomesh wrote:
> > Can you point me to code where kernel captures process in signal
> > handling and code which runs after suspend to ram is finished?
> 
> Sure.
> 
> It's in kernel/signal.c (get_signal_to_deliver) for x86 and x86_64, and 
> arch/<name>/kernel/signal.c for other arches. The support for other arches is 
> the place x86 & x86_64 used to use - I wonder if they should be going away 
> (Rafael cc'd to raise this point with him).

That's a good question. :-)  I'll have a look.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: which signal is sent to freeze process?

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

Hi.

On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote:
> So basically I can not install a signal handler to catch freeze signal
> in the process. Right?
> Is there any other way to solve the problem I am facing? After resume
> some of the system calls are failing in some of my applications with
> errno set as EINTR. I wanted to explore a way to not check for this
> error all over the place and somehow retry failed system call. Any
> ideas?

Well, if you tell us which syscalls are returning with EINTR, maybe we can do 
something on our side. The freezer is supposed to be as transparent as 
possible to userspace, so it may be the case that we can do something to 
continue waiting or whatever you were doing after the freezing is done.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

I am using Linux in an embedded platform with x86. Applications don't do
anything special. The system call which is returning EINTR is poll. Also
in one of the thread read is returning ENODATA after resume. If I just
try the system calls again in case of EINTR or ENODATA everything works
fine.
>From your mail it looks like freezer is not supposed to be interrupting
system calls. Is that true?

-----Original Message-----
From: Nigel Cunningham [mailto:nigel@nigel.suspend2.net] 
Sent: Thursday, July 19, 2007 3:19 PM
To: Agarwal, Lomesh
Cc: nigel@suspend2.net; Rafael Wysocki; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?

Hi.

On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote:
> So basically I can not install a signal handler to catch freeze signal
> in the process. Right?
> Is there any other way to solve the problem I am facing? After resume
> some of the system calls are failing in some of my applications with
> errno set as EINTR. I wanted to explore a way to not check for this
> error all over the place and somehow retry failed system call. Any
> ideas?

Well, if you tell us which syscalls are returning with EINTR, maybe we
can do 
something on our side. The freezer is supposed to be as transparent as 
possible to userspace, so it may be the case that we can do something to

continue waiting or whatever you were doing after the freezing is done.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Friday, 20 July 2007 01:22, Agarwal, Lomesh wrote:
> I am using Linux in an embedded platform with x86. Applications don't do
> anything special. The system call which is returning EINTR is poll. Also
> in one of the thread read is returning ENODATA after resume. If I just
> try the system calls again in case of EINTR or ENODATA everything works
> fine.
> From your mail it looks like freezer is not supposed to be interrupting
> system calls. Is that true?

Yes, it is, or at least it should be.

The signal handling is invoked when the process is exiting the kernel space
and it shouldn't affect the execution or results of system calls.

Greetings,
Rafael


> -----Original Message-----
> From: Nigel Cunningham [mailto:nigel@nigel.suspend2.net] 
> Sent: Thursday, July 19, 2007 3:19 PM
> To: Agarwal, Lomesh
> Cc: nigel@suspend2.net; Rafael Wysocki; linux-kernel@vger.kernel.org
> Subject: Re: which signal is sent to freeze process?
> 
> Hi.
> 
> On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote:
> > So basically I can not install a signal handler to catch freeze signal
> > in the process. Right?
> > Is there any other way to solve the problem I am facing? After resume
> > some of the system calls are failing in some of my applications with
> > errno set as EINTR. I wanted to explore a way to not check for this
> > error all over the place and somehow retry failed system call. Any
> > ideas?
> 
> Well, if you tell us which syscalls are returning with EINTR, maybe we
> can do 
> something on our side. The freezer is supposed to be as transparent as 
> possible to userspace, so it may be the case that we can do something to
> 
> continue waiting or whatever you were doing after the freezing is done.
> 
> Regards,
> 
> Nigel

-- 
"Premature optimization is the root of all evil." - Donald Knuth

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

Can you suggest a way I can debug the issue why I am getting EINTR error
for system calls in resuming? What else can cause the system call
failure with EINTR?

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
Sent: Friday, July 20, 2007 4:24 AM
To: Agarwal, Lomesh
Cc: nigel@suspend2.net; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?

On Friday, 20 July 2007 01:22, Agarwal, Lomesh wrote:
> I am using Linux in an embedded platform with x86. Applications don't
do
> anything special. The system call which is returning EINTR is poll.
Also
> in one of the thread read is returning ENODATA after resume. If I just
> try the system calls again in case of EINTR or ENODATA everything
works
> fine.
> From your mail it looks like freezer is not supposed to be
interrupting
> system calls. Is that true?

Yes, it is, or at least it should be.

The signal handling is invoked when the process is exiting the kernel
space
and it shouldn't affect the execution or results of system calls.

Greetings,
Rafael


> -----Original Message-----
> From: Nigel Cunningham [mailto:nigel@nigel.suspend2.net] 
> Sent: Thursday, July 19, 2007 3:19 PM
> To: Agarwal, Lomesh
> Cc: nigel@suspend2.net; Rafael Wysocki; linux-kernel@vger.kernel.org
> Subject: Re: which signal is sent to freeze process?
> 
> Hi.
> 
> On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote:
> > So basically I can not install a signal handler to catch freeze
signal
> > in the process. Right?
> > Is there any other way to solve the problem I am facing? After
resume
> > some of the system calls are failing in some of my applications with
> > errno set as EINTR. I wanted to explore a way to not check for this
> > error all over the place and somehow retry failed system call. Any
> > ideas?
> 
> Well, if you tell us which syscalls are returning with EINTR, maybe we
> can do 
> something on our side. The freezer is supposed to be as transparent as

> possible to userspace, so it may be the case that we can do something
to
> 
> continue waiting or whatever you were doing after the freezing is
done.
> 
> Regards,
> 
> Nigel

-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> Can you suggest a way I can debug the issue why I am getting EINTR error
> for system calls in resuming? What else can cause the system call
> failure with EINTR?

Well, I think I know what the problem is.  do_poll checks
signal_pending(current) and breaks when it's set, but that may be caused
by the freezer.

You may try the patch below (untested) and see if that helps.

Greetings,
Rafael


---
 fs/select.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6.22-rc6-mm1/fs/select.c
===================================================================
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
 #include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/rcupdate.h>
+#include <linux/freezer.h>
 
 #include <asm/uaccess.h>
 
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds,  s
 		struct poll_list *walk;
 		long __timeout;
 
+		try_to_freeze();
+
 		set_current_state(TASK_INTERRUPTIBLE);
 		for (walk = list; walk != NULL; walk = walk->next) {
 			struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds,  s
 		 * a poll_table to them on the next loop iteration.
 		 */
 		pt = NULL;
-		if (count || !*timeout || signal_pending(current))
+		if (count || !*timeout ||
+		    (signal_pending(current) && !freezing(current)))
 			break;
 		count = wait->error;
 		if (count)

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

The other problem I am facing that read from socket returns with ENODATA
when resuming. any ideas?

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: nigel@suspend2.net; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?

On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> Can you suggest a way I can debug the issue why I am getting EINTR
error
> for system calls in resuming? What else can cause the system call
> failure with EINTR?

Well, I think I know what the problem is.  do_poll checks
signal_pending(current) and breaks when it's set, but that may be caused
by the freezer.

You may try the patch below (untested) and see if that helps.

Greetings,
Rafael


---
 fs/select.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6.22-rc6-mm1/fs/select.c
===================================================================
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
 #include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/rcupdate.h>
+#include <linux/freezer.h>
 
 #include <asm/uaccess.h>
 
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds,  s
 		struct poll_list *walk;
 		long __timeout;
 
+		try_to_freeze();
+
 		set_current_state(TASK_INTERRUPTIBLE);
 		for (walk = list; walk != NULL; walk = walk->next) {
 			struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds,  s
 		 * a poll_table to them on the next loop iteration.
 		 */
 		pt = NULL;
-		if (count || !*timeout || signal_pending(current))
+		if (count || !*timeout ||
+		    (signal_pending(current) && !freezing(current)))
 			break;
 		count = wait->error;
 		if (count)

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Monday, 23 July 2007 20:38, Agarwal, Lomesh wrote:
> The other problem I am facing that read from socket returns with ENODATA
> when resuming. any ideas?

It's of similar kind: the system call checks signal_pending(current) and exit
with an error if that's true.

Well, I'm afraid we can't place try_to_freeze() in every system call that
does something like that ...

Greetings,
Rafael


> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
> Sent: Friday, July 20, 2007 3:10 PM
> To: Agarwal, Lomesh
> Cc: nigel@suspend2.net; linux-kernel@vger.kernel.org
> Subject: Re: which signal is sent to freeze process?
> 
> On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> > Can you suggest a way I can debug the issue why I am getting EINTR
> error
> > for system calls in resuming? What else can cause the system call
> > failure with EINTR?
> 
> Well, I think I know what the problem is.  do_poll checks
> signal_pending(current) and breaks when it's set, but that may be caused
> by the freezer.
> 
> You may try the patch below (untested) and see if that helps.
> 
> Greetings,
> Rafael
> 
> 
> ---
>  fs/select.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.22-rc6-mm1/fs/select.c
> ===================================================================
> --- linux-2.6.22-rc6-mm1.orig/fs/select.c
> +++ linux-2.6.22-rc6-mm1/fs/select.c
> @@ -23,6 +23,7 @@
>  #include <linux/file.h>
>  #include <linux/fs.h>
>  #include <linux/rcupdate.h>
> +#include <linux/freezer.h>
>  
>  #include <asm/uaccess.h>
>  
> @@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds,  s
>  		struct poll_list *walk;
>  		long __timeout;
>  
> +		try_to_freeze();
> +
>  		set_current_state(TASK_INTERRUPTIBLE);
>  		for (walk = list; walk != NULL; walk = walk->next) {
>  			struct pollfd * pfd, * pfd_end;
> @@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds,  s
>  		 * a poll_table to them on the next loop iteration.
>  		 */
>  		pt = NULL;
> -		if (count || !*timeout || signal_pending(current))
> +		if (count || !*timeout ||
> +		    (signal_pending(current) && !freezing(current)))
>  			break;
>  		count = wait->error;
>  		if (count)
> 
> 

-- 
"Premature optimization is the root of all evil." - Donald Knuth

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

Then what would be the correct way to handle resume process. The other
way of course is to make all the applications check the errno in case of
failure. But that seems more more problematic then system call checking.
What do you say?
BTW can you point me to code where socket read checks for
signal_pending(current)?

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
Sent: Monday, July 23, 2007 12:25 PM
To: Agarwal, Lomesh
Cc: nigel@suspend2.net; linux-kernel@vger.kernel.org; Pavel Machek
Subject: Re: which signal is sent to freeze process?

On Monday, 23 July 2007 20:38, Agarwal, Lomesh wrote:
> The other problem I am facing that read from socket returns with
ENODATA
> when resuming. any ideas?

It's of similar kind: the system call checks signal_pending(current) and
exit
with an error if that's true.

Well, I'm afraid we can't place try_to_freeze() in every system call
that
does something like that ...

Greetings,
Rafael


> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
> Sent: Friday, July 20, 2007 3:10 PM
> To: Agarwal, Lomesh
> Cc: nigel@suspend2.net; linux-kernel@vger.kernel.org
> Subject: Re: which signal is sent to freeze process?
> 
> On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> > Can you suggest a way I can debug the issue why I am getting EINTR
> error
> > for system calls in resuming? What else can cause the system call
> > failure with EINTR?
> 
> Well, I think I know what the problem is.  do_poll checks
> signal_pending(current) and breaks when it's set, but that may be
caused
> by the freezer.
> 
> You may try the patch below (untested) and see if that helps.
> 
> Greetings,
> Rafael
> 
> 
> ---
>  fs/select.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.22-rc6-mm1/fs/select.c
> ===================================================================
> --- linux-2.6.22-rc6-mm1.orig/fs/select.c
> +++ linux-2.6.22-rc6-mm1/fs/select.c
> @@ -23,6 +23,7 @@
>  #include <linux/file.h>
>  #include <linux/fs.h>
>  #include <linux/rcupdate.h>
> +#include <linux/freezer.h>
>  
>  #include <asm/uaccess.h>
>  
> @@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds,  s
>  		struct poll_list *walk;
>  		long __timeout;
>  
> +		try_to_freeze();
> +
>  		set_current_state(TASK_INTERRUPTIBLE);
>  		for (walk = list; walk != NULL; walk = walk->next) {
>  			struct pollfd * pfd, * pfd_end;
> @@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds,  s
>  		 * a poll_table to them on the next loop iteration.
>  		 */
>  		pt = NULL;
> -		if (count || !*timeout || signal_pending(current))
> +		if (count || !*timeout ||
> +		    (signal_pending(current) && !freezing(current)))
>  			break;
>  		count = wait->error;
>  		if (count)
> 
> 

-- 
"Premature optimization is the root of all evil." - Donald Knuth

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

Why do you need try_to_freeze in below patch? Shouldn't
!freezing(current) checking is enough?

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: nigel@suspend2.net; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?

On Friday, 20 July 2007 20:07, Agarwal, Lomesh wrote:
> Can you suggest a way I can debug the issue why I am getting EINTR
error
> for system calls in resuming? What else can cause the system call
> failure with EINTR?

Well, I think I know what the problem is.  do_poll checks
signal_pending(current) and breaks when it's set, but that may be caused
by the freezer.

You may try the patch below (untested) and see if that helps.

Greetings,
Rafael


---
 fs/select.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6.22-rc6-mm1/fs/select.c
===================================================================
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -23,6 +23,7 @@
 #include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/rcupdate.h>
+#include <linux/freezer.h>
 
 #include <asm/uaccess.h>
 
@@ -593,6 +594,8 @@ static int do_poll(unsigned int nfds,  s
 		struct poll_list *walk;
 		long __timeout;
 
+		try_to_freeze();
+
 		set_current_state(TASK_INTERRUPTIBLE);
 		for (walk = list; walk != NULL; walk = walk->next) {
 			struct pollfd * pfd, * pfd_end;
@@ -618,7 +621,8 @@ static int do_poll(unsigned int nfds,  s
 		 * a poll_table to them on the next loop iteration.
 		 */
 		pt = NULL;
-		if (count || !*timeout || signal_pending(current))
+		if (count || !*timeout ||
+		    (signal_pending(current) && !freezing(current)))
 			break;
 		count = wait->error;
 		if (count)

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Monday, 23 July 2007 22:57, Agarwal, Lomesh wrote:
> Why do you need try_to_freeze in below patch? Shouldn't
> !freezing(current) checking is enough?

The try_to_freeze() is needed so that the process doesn't block the freezing
of tasks (it is supposed to call refrigerator() as soon as reasonably possible
when freezing(current) is true).

Alternatively, we might return 0 from do_sys_poll() if do_poll() has
returned 0 and both signal_pending(current) and freezing(current) are
true.  Below is a patch that implements that.  Could you please try it?

Greetings,
Rafael


---
 fs/select.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.22-rc6-mm1/fs/select.c
===================================================================
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -722,7 +722,7 @@ int do_sys_poll(struct pollfd __user *uf
 		walk = walk->next;
   	}
 	err = fdcount;
-	if (!fdcount && signal_pending(current))
+	if (!fdcount && (signal_pending(current) && !freezing(current)))
 		err = -EINTR;
 out_fds:
 	walk = head;

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

The net effect would be same. Why would you choose one over other
(do_sys_poll vs. do_poll)?
Can you point me to code where socket read returns in case of
signal_pending? I need to try couple of things.

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
Sent: Monday, July 23, 2007 2:51 PM
To: Agarwal, Lomesh
Cc: nigel@suspend2.net; linux-kernel@vger.kernel.org
Subject: Re: which signal is sent to freeze process?

On Monday, 23 July 2007 22:57, Agarwal, Lomesh wrote:
> Why do you need try_to_freeze in below patch? Shouldn't
> !freezing(current) checking is enough?

The try_to_freeze() is needed so that the process doesn't block the
freezing
of tasks (it is supposed to call refrigerator() as soon as reasonably
possible
when freezing(current) is true).

Alternatively, we might return 0 from do_sys_poll() if do_poll() has
returned 0 and both signal_pending(current) and freezing(current) are
true.  Below is a patch that implements that.  Could you please try it?

Greetings,
Rafael


---
 fs/select.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.22-rc6-mm1/fs/select.c
===================================================================
--- linux-2.6.22-rc6-mm1.orig/fs/select.c
+++ linux-2.6.22-rc6-mm1/fs/select.c
@@ -722,7 +722,7 @@ int do_sys_poll(struct pollfd __user *uf
 		walk = walk->next;
   	}
 	err = fdcount;
-	if (!fdcount && signal_pending(current))
+	if (!fdcount && (signal_pending(current) && !freezing(current)))
 		err = -EINTR;
 out_fds:
 	walk = head;

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Tuesday, 24 July 2007 00:18, Agarwal, Lomesh wrote:
> The net effect would be same. Why would you choose one over other
> (do_sys_poll vs. do_poll)?

The last patch is simpler and it doesn't involve the try_to_freeze() thing.

> Can you point me to code where socket read returns in case of
> signal_pending? I need to try couple of things.

I need to find it myself, first. ;-)

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: which signal is sent to freeze process?

[Pavel Machek]

Hi!

Can you generate small testcase that demonstrates the problem?

> Then what would be the correct way to handle resume process. The other
> way of course is to make all the applications check the errno in case of
> failure. But that seems more more problematic then system call checking.
> What do you say?

Hmm, does that testcase behave correctly over SIGSTOP/SIGCONT? I'm not
saying kernel behaves nicely here, but perhaps fixing the apps to
check errno properly is the right thing to do? :-)
								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: which signal is sent to freeze process?

[Pavel Machek]

Hi!

> On Thursday 19 July 2007 14:09:56 Agarwal, Lomesh wrote:
> > Can you point me to code where kernel captures process in signal
> > handling and code which runs after suspend to ram is finished?
> 
> Sure.
> 
> It's in kernel/signal.c (get_signal_to_deliver) for x86 and x86_64, and 
> arch/<name>/kernel/signal.c for other arches. The support for other arches is 
> the place x86 & x86_64 used to use - I wonder if they should be going away 
> (Rafael cc'd to raise this point with him).

...and you want to look at kernel/power/process.c, too.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: which signal is sent to freeze process?

[Pavel Machek]

Hi!

> >Can you generate small testcase that demonstrates the problem?
> >
> >> Then what would be the correct way to handle resume process. The other
> >> way of course is to make all the applications check the errno in case of
> >> failure. But that seems more more problematic then system call checking.
> >> What do you say?
> >
> >Hmm, does that testcase behave correctly over SIGSTOP/SIGCONT? I'm not
> >saying kernel behaves nicely here, but perhaps fixing the apps to
> >check errno properly is the right thing to do? :-)
> Perhaps the kernel should use ERESTARTNOHAND instead of EINTR?
> The current code is more than odd:
> - select() and sys_ppoll() both use ERESTARTNOHAND (i.e.: 
> the functions do not return to user space with SIGSTOP/SIGCONT or freezer())
> 
> - sys_poll() uses EINTR (i.e.: SIGSTOP/SIGCONT/freezer() return to user 
> space)
> 
> Attached is a patch that switches sys_poll to ERESTARTNOHAND and a poll 
> test app.
> Boot tested with FC6.
> 
> What do you think? With ERESTARTNOHAND, poll would only return to user 
> space if the app has a SIGCONT handler installed.

I think the patch looks okay... but I expected some discussoin here
and it did not happen :-(. Can you try to send it to andrew?

> --- 2.6/fs/select.c	2007-05-20 09:52:32.000000000 +0200
> +++ build-2.6/fs/select.c	2007-07-23 22:10:21.000000000 +0200
> @@ -723,7 +723,7 @@
>    	}
>  	err = fdcount;
>  	if (!fdcount && signal_pending(current))
> -		err = -EINTR;
> +		err = -ERESTARTNOHAND;
>  out_fds:
>  	walk = head;
>  	while(walk!=NULL) {
> @@ -794,7 +794,7 @@
>  	ret = do_sys_poll(ufds, nfds, &timeout);
>  
>  	/* We can restart this syscall, usually */
> -	if (ret == -EINTR) {
> +	if (ret == -ERESTARTNOHAND) {
>  		/*
>  		 * Don't restore the signal mask yet. Let do_signal() deliver
>  		 * the signal on the way back to userspace, before the signal
> @@ -805,7 +805,6 @@
>  					sizeof(sigsaved));
>  			set_thread_flag(TIF_RESTORE_SIGMASK);
>  		}
> -		ret = -ERESTARTNOHAND;
>  	} else if (sigmask)
>  		sigprocmask(SIG_SETMASK, &sigsaved, NULL);
>  

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: which signal is sent to freeze process?

[Agarwal, Lomesh]

This patch works for me too.

-----Original Message-----
From: Manfred Spraul [mailto:manfred@colorfullife.com] 
Sent: Tuesday, July 24, 2007 11:49 AM
To: Pavel Machek
Cc: Rafael J. Wysocki; linux-kernel@vger.kernel.org; Agarwal, Lomesh;
Nigel Cunningham
Subject: Re: which signal is sent to freeze process?

> Hi!
>
> Can you generate small testcase that demonstrates the problem?
>
> > Then what would be the correct way to handle resume process. The
other
> > way of course is to make all the applications check the errno in
case of
> > failure. But that seems more more problematic then system call
checking.
> > What do you say?
>
> Hmm, does that testcase behave correctly over SIGSTOP/SIGCONT? I'm not
> saying kernel behaves nicely here, but perhaps fixing the apps to
> check errno properly is the right thing to do? :-)
Perhaps the kernel should use ERESTARTNOHAND instead of EINTR?
The current code is more than odd:
- select() and sys_ppoll() both use ERESTARTNOHAND (i.e.: 
the functions do not return to user space with SIGSTOP/SIGCONT or
freezer())

- sys_poll() uses EINTR (i.e.: SIGSTOP/SIGCONT/freezer() return to user
space)

Attached is a patch that switches sys_poll to ERESTARTNOHAND and a poll
test app.
Boot tested with FC6.

What do you think? With ERESTARTNOHAND, poll would only return to user
space if the app has a SIGCONT handler installed.

--
	Manfred

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Tuesday, 24 July 2007 20:48, Manfred Spraul wrote:
> > Hi!
> >
> > Can you generate small testcase that demonstrates the problem?
> >
> > > Then what would be the correct way to handle resume process. The other
> > > way of course is to make all the applications check the errno in case of
> > > failure. But that seems more more problematic then system call checking.
> > > What do you say?
> >
> > Hmm, does that testcase behave correctly over SIGSTOP/SIGCONT? I'm not
> > saying kernel behaves nicely here, but perhaps fixing the apps to
> > check errno properly is the right thing to do? :-)
> Perhaps the kernel should use ERESTARTNOHAND instead of EINTR?
> The current code is more than odd:
> - select() and sys_ppoll() both use ERESTARTNOHAND (i.e.: 
> the functions do not return to user space with SIGSTOP/SIGCONT or freezer())
> 
> - sys_poll() uses EINTR (i.e.: SIGSTOP/SIGCONT/freezer() return to user space)
> 
> Attached is a patch that switches sys_poll to ERESTARTNOHAND and a poll test app.
> Boot tested with FC6.
> 
> What do you think? With ERESTARTNOHAND, poll would only return to user space if the app has a SIGCONT handler installed.

Well, I don't know why sys_poll() uses EINTR, so I don't know if that's not for
a reason.  Using ERESTARTNOHAND instead of it seems to be a good idea, though.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: which signal is sent to freeze process?

[Manfred Spraul]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

> Hi!
>
> Can you generate small testcase that demonstrates the problem?
>
> > Then what would be the correct way to handle resume process. The other
> > way of course is to make all the applications check the errno in case of
> > failure. But that seems more more problematic then system call checking.
> > What do you say?
>
> Hmm, does that testcase behave correctly over SIGSTOP/SIGCONT? I'm not
> saying kernel behaves nicely here, but perhaps fixing the apps to
> check errno properly is the right thing to do? :-)
Perhaps the kernel should use ERESTARTNOHAND instead of EINTR?
The current code is more than odd:
- select() and sys_ppoll() both use ERESTARTNOHAND (i.e.: 
the functions do not return to user space with SIGSTOP/SIGCONT or freezer())

- sys_poll() uses EINTR (i.e.: SIGSTOP/SIGCONT/freezer() return to user space)

Attached is a patch that switches sys_poll to ERESTARTNOHAND and a poll test app.
Boot tested with FC6.

What do you think? With ERESTARTNOHAND, poll would only return to user space if the app has a SIGCONT handler installed.

--
	Manfred


[-- Attachment #2: patch-poll-ERESTARTNOHAND --]
[-- Type: text/plain, Size: 783 bytes --]

--- 2.6/fs/select.c	2007-05-20 09:52:32.000000000 +0200
+++ build-2.6/fs/select.c	2007-07-23 22:10:21.000000000 +0200
@@ -723,7 +723,7 @@
   	}
 	err = fdcount;
 	if (!fdcount && signal_pending(current))
-		err = -EINTR;
+		err = -ERESTARTNOHAND;
 out_fds:
 	walk = head;
 	while(walk!=NULL) {
@@ -794,7 +794,7 @@
 	ret = do_sys_poll(ufds, nfds, &timeout);
 
 	/* We can restart this syscall, usually */
-	if (ret == -EINTR) {
+	if (ret == -ERESTARTNOHAND) {
 		/*
 		 * Don't restore the signal mask yet. Let do_signal() deliver
 		 * the signal on the way back to userspace, before the signal
@@ -805,7 +805,6 @@
 					sizeof(sigsaved));
 			set_thread_flag(TIF_RESTORE_SIGMASK);
 		}
-		ret = -ERESTARTNOHAND;
 	} else if (sigmask)
 		sigprocmask(SIG_SETMASK, &sigsaved, NULL);
 

[-- Attachment #3: sp.cpp --]
[-- Type: text/x-c++src, Size: 789 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/poll.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <errno.h>

int main(int argc, char **argv)
{
	int delay, ret;
	struct pollfd pfd;
	int pipesfd[2];

	printf("sp <delay>\n");

	if (argc != 2)
		return 1;
	delay = atoi(argv[1]);
	printf("delay %d.\n", delay);
	if (delay < 0 || delay > 1000)
		return 2;

	if (pipe(pipesfd) != 0) {
		fprintf(stderr, "pipe failed with errno %d.\n", errno);
		return 3;
	}
	pfd.fd = pipesfd[0];
	pfd.events = POLLIN;

	if (!fork()) {
		sleep(delay);
		write(pipesfd[1], "", 1);;
		return 0;
	}
	sleep(1);
	ret = poll(&pfd, 1, -1);
	printf("poll returned %d.\n", ret);

	if (pfd.revents)
		printf("   events %8xh revents %8xh.\n", pfd.events, pfd.revents);

	return 0;
}

Re: which signal is sent to freeze process?

[Rafael J. Wysocki]

On Monday, 23 July 2007 21:52, Manfred Spraul wrote:
> Rafael wrote:
> > On Monday, 23 July 2007 20:38, Agarwal, Lomesh wrote:
> > > The other problem I am facing that read from socket returns with ENODATA
> > > when resuming. any ideas?
> >
> > It's of similar kind: the system call checks signal_pending(current) and exit
> > with an error if that's true.
> >
> > Well, I'm afraid we can't place try_to_freeze() in every system call that
> > does something like that ...
> >   
> I don't understand why the poll() system call returns to user space. 
> poll() uses ERESTARTNOHAND, thus it should not return to user space.
> Any ideas why ERESTARTNOHAND doesn't work?

Well, look at the code in fs/select.c:do_poll() .  If signal_pending(current)
is true, the main loop breaks and count is returned to do_sys_poll().  If
zero is returned and signal_pending(current) is still true, do_sys_poll()
returns -EINTR.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: which signal is sent to freeze process?

[Manfred Spraul]

Rafael J. Wysocki wrote:
> Well, look at the code in fs/select.c:do_poll() .  If signal_pending(current)
> is true, the main loop breaks and count is returned to do_sys_poll().  If
> zero is returned and signal_pending(current) is still true, do_sys_poll()
> returns -EINTR.
>
>   
Thanks - I looked at sys_ppoll().
sys_ppoll() and select() use ERESTARTNOHAND, sys_poll uses EINTR.

--
    Manfred

RE: which signal is sent to freeze process?

[Manfred Spraul]

Rafael wrote:
> On Monday, 23 July 2007 20:38, Agarwal, Lomesh wrote:
> > The other problem I am facing that read from socket returns with ENODATA
> > when resuming. any ideas?
>
> It's of similar kind: the system call checks signal_pending(current) and exit
> with an error if that's true.
>
> Well, I'm afraid we can't place try_to_freeze() in every system call that
> does something like that ...
>   
I don't understand why the poll() system call returns to user space. 
poll() uses ERESTARTNOHAND, thus it should not return to user space.
Any ideas why ERESTARTNOHAND doesn't work?

--
    Manfred