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.
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.0 +0200
> +++ build-2.6/fs/select.c 2007-07-23 22:10:21.0 +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, );
>
> /* 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, , NULL);
>
--
(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: 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.
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.0 +0200
+++ build-2.6/fs/select.c 2007-07-23 22:10:21.0 +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
-
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: which signal is sent to freeze process?
This patch works for me too. -Original Message- From: Manfred Spraul [mailto:[EMAIL PROTECTED] 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 - 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: which signal is sent to freeze process?
This patch works for me too. -Original Message- From: Manfred Spraul [mailto:[EMAIL PROTECTED] 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 - 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: which signal is sent to freeze process?
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 - 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: 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//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 - 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: which signal is sent to freeze process?
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 - 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: 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). ...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 - 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: 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
--- 2.6/fs/select.c 2007-05-20 09:52:32.0 +0200
+++ build-2.6/fs/select.c 2007-07-23 22:10:21.0 +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, );
/* 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, , NULL);
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
int delay, ret;
struct pollfd pfd;
int pipesfd[2];
printf("sp \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(, 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?
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 - 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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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 - 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: 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? :-) 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: 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
--- 2.6/fs/select.c 2007-05-20 09:52:32.0 +0200
+++ build-2.6/fs/select.c 2007-07-23 22:10:21.0 +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);
#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?
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:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 2:51 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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; - 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: 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; - 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: which signal is sent to freeze process?
Why do you need try_to_freeze in below patch? Shouldn't
!freezing(current) checking is enough?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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
#include
#include
+#include
#include
@@ -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)
-
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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 12:25 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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:[EMAIL PROTECTED]
> Sent: Friday, July 20, 2007 3:10 PM
> To: Agarwal, Lomesh
> Cc: [EMAIL PROTECTED]; 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
> #include
> #include
> +#include
>
> #include
>
> @@ -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
-
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: 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:[EMAIL PROTECTED]
> Sent: Friday, July 20, 2007 3:10 PM
> To: Agarwal, Lomesh
> Cc: [EMAIL PROTECTED]; 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
> #include
> #include
> +#include
>
> #include
>
> @@ -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
-
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: which signal is sent to freeze process?
The other problem I am facing that read from socket returns with ENODATA
when resuming. any ideas?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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
#include
#include
+#include
#include
@@ -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)
-
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: which signal is sent to freeze process?
The other problem I am facing that read from socket returns with ENODATA
when resuming. any ideas?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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)
-
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: 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:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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
-
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: which signal is sent to freeze process?
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:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 12:25 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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
-
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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
Why do you need try_to_freeze in below patch? Shouldn't
!freezing(current) checking is enough?
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 3:10 PM
To: Agarwal, Lomesh
Cc: [EMAIL PROTECTED]; 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)
-
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: 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; - 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: which signal is sent to freeze process?
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:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 2:51 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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; - 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: 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
#include
#include
+#include
#include
@@ -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)
-
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: which signal is sent to freeze process?
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:[EMAIL PROTECTED] Sent: Friday, July 20, 2007 4:24 AM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 3:19 PM > To: Agarwal, Lomesh > Cc: [EMAIL PROTECTED]; 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 - 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: 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:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 3:19 PM > To: Agarwal, Lomesh > Cc: [EMAIL PROTECTED]; 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 - 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: 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:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 3:19 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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 - 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: which signal is sent to freeze process?
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:[EMAIL PROTECTED] Sent: Friday, July 20, 2007 4:24 AM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 3:19 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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 - 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: 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)
-
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: which signal is sent to freeze process?
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:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 3:19 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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. - 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: 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. pgpREPjM7ETum.pgp Description: PGP signature
Re: which signal is sent to freeze process?
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//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 - 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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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:[EMAIL PROTECTED] 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//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. - 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: which signal is sent to freeze process?
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:[EMAIL PROTECTED] 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. - 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: which signal is sent to freeze process?
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 - 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: which signal is sent to freeze process?
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 - 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: 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. pgpREPjM7ETum.pgp Description: PGP signature
RE: which signal is sent to freeze process?
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:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 3:19 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; 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. - 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: 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//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. pgp94ZPnp6nG3.pgp Description: PGP signature
RE: which signal is sent to freeze process?
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:[EMAIL PROTECTED] 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 - 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: 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 pgpYLhbe5oi6T.pgp Description: PGP signature
which signal is sent to freeze process?
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 - 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/
which signal is sent to freeze process?
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 - 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: 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 pgpYLhbe5oi6T.pgp Description: PGP signature
RE: which signal is sent to freeze process?
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:[EMAIL PROTECTED] 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 - 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: 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. pgp94ZPnp6nG3.pgp Description: PGP signature
