linux-kernel - RE: which signal is sent to freeze process?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Jul 2007 12:31:03 -0700
From:	"Agarwal, Lomesh" <lomesh.agarwal@...el.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	<nigel@...pend2.net>, <linux-kernel@...r.kernel.org>,
	"Pavel Machek" <pavel@....cz>
Subject: 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:rjw@...k.pl] 
Sent: Monday, July 23, 2007 12:25 PM
To: Agarwal, Lomesh
Cc: nigel@...pend2.net; linux-kernel@...r.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@...k.pl] 
> Sent: Friday, July 20, 2007 3:10 PM
> To: Agarwal, Lomesh
> Cc: nigel@...pend2.net; linux-kernel@...r.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/