* Change signal mask after vfork/clone system call
@ 2010-10-19 7:53 Gregory Giguashvili
2010-10-20 7:56 ` Gregory Giguashvili
2010-11-04 6:08 ` Gregory Giguashvili
0 siblings, 2 replies; 10+ messages in thread
From: Gregory Giguashvili @ 2010-10-19 7:53 UTC (permalink / raw)
To: linux-kernel
For new processes created by vfork, while signals are blocked using pthread_sigmask: is there a way in a multi-threaded parent to safely unblock signals before the new process is started? Does pthread_atfork like functionality exist for vfork-ed processes maybe?
Ideally, the following code should work, except we're not allowed to call anything in the child process besides exec family of functions.
sigmask_t new;
sigmask_t old;
sigaddset (&new, SIGCHLD);
pthread_sigmask (SIG_BLOCK, &new, &old);
switch (vfork ()) {
case 0: // parent
break;
case -1: // error
break;
default: // child
pthread_sigmask (SIG_SETMASK, &old, NULL);
execv (...);
_exit (-1);
}
Finally, if using fork should be efficient for starting processes from applications with heavy VM/RSS memory footprint, this question becomes obsolete.
Thanks
Giga
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ permalink raw reply [flat|nested] 10+ messages in thread* RE: Change signal mask after vfork/clone system call
2010-10-19 7:53 Change signal mask after vfork/clone system call Gregory Giguashvili
@ 2010-10-20 7:56 ` Gregory Giguashvili
2010-11-04 6:08 ` Gregory Giguashvili
1 sibling, 0 replies; 10+ messages in thread
From: Gregory Giguashvili @ 2010-10-20 7:56 UTC (permalink / raw)
To: linux-kernel
Any comments on this issue? If you think this mailing list is not appropriate for submitting such questions, I would appreciate a pointer to the one that is.
To me, it seems to be related to "clone" system call functionality and flexibility.
Thanks
Giga
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Gregory Giguashvili
Sent: Tuesday, October 19, 2010 9:54 AM
To: linux-kernel@vger.kernel.org
Subject: Change signal mask after vfork/clone system call
For new processes created by vfork, while signals are blocked using pthread_sigmask: is there a way in a multi-threaded parent to safely unblock signals before the new process is started? Does pthread_atfork like functionality exist for vfork-ed processes maybe?
Ideally, the following code should work, except we're not allowed to call anything in the child process besides exec family of functions.
sigmask_t new;
sigmask_t old;
sigaddset (&new, SIGCHLD);
pthread_sigmask (SIG_BLOCK, &new, &old);
switch (vfork ()) {
case 0: // parent
break;
case -1: // error
break;
default: // child
pthread_sigmask (SIG_SETMASK, &old, NULL);
execv (...);
_exit (-1);
}
Finally, if using fork should be efficient for starting processes from applications with heavy VM/RSS memory footprint, this question becomes obsolete.
Thanks
Giga
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ permalink raw reply [flat|nested] 10+ messages in thread* RE: Change signal mask after vfork/clone system call
2010-10-19 7:53 Change signal mask after vfork/clone system call Gregory Giguashvili
2010-10-20 7:56 ` Gregory Giguashvili
@ 2010-11-04 6:08 ` Gregory Giguashvili
2010-11-04 9:48 ` Alan Cox
1 sibling, 1 reply; 10+ messages in thread
From: Gregory Giguashvili @ 2010-11-04 6:08 UTC (permalink / raw)
To: linux-kernel
Any comments on this issue? Is there a way to prevent signal mask inheritance when using vfork?
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Gregory Giguashvili
Sent: Tuesday, October 19, 2010 9:54 AM
To: linux-kernel@vger.kernel.org
Subject: Change signal mask after vfork/clone system call
For new processes created by vfork, while signals are blocked using pthread_sigmask: is there a way in a multi-threaded parent to safely unblock signals before the new process is started? Does pthread_atfork like functionality exist for vfork-ed processes maybe?
Ideally, the following code should work, except we're not allowed to call anything in the child process besides exec family of functions.
sigmask_t new;
sigmask_t old;
sigaddset (&new, SIGCHLD);
pthread_sigmask (SIG_BLOCK, &new, &old);
switch (vfork ()) {
case 0: // parent
break;
case -1: // error
break;
default: // child
pthread_sigmask (SIG_SETMASK, &old, NULL);
execv (...);
_exit (-1);
}
Finally, if using fork should be efficient for starting processes from applications with heavy VM/RSS memory footprint, this question becomes obsolete.
Thanks
Giga
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Change signal mask after vfork/clone system call
2010-11-04 6:08 ` Gregory Giguashvili
@ 2010-11-04 9:48 ` Alan Cox
2010-11-04 15:37 ` Gregory Giguashvili
2010-11-05 7:32 ` Gregory Giguashvili
0 siblings, 2 replies; 10+ messages in thread
From: Alan Cox @ 2010-11-04 9:48 UTC (permalink / raw)
To: Gregory Giguashvili; +Cc: linux-kernel
> Finally, if using fork should be efficient for starting processes from applications with heavy VM/RSS memory footprint, this question becomes obsolete.
Fork on pretty much any Unix like system around today does copy-on-write
so while not as efficient as vfork should be fine for most purposes.
Alan
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Change signal mask after vfork/clone system call
2010-11-04 9:48 ` Alan Cox
@ 2010-11-04 15:37 ` Gregory Giguashvili
2010-11-04 15:45 ` Alan Cox
2010-11-05 7:32 ` Gregory Giguashvili
1 sibling, 1 reply; 10+ messages in thread
From: Gregory Giguashvili @ 2010-11-04 15:37 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
> Fork on pretty much any Unix like system around today does copy-on-write
>so while not as efficient as vfork should be fine for most purposes.
Yes, but the problem is that fork simply does not work when a process has huge resident size and vm.overcommit_memory=0 as preferred by Linux distributions we run on. So, processes with large RSS footprint may occasionally fail fork, even if a tiny process is to be started.
Using vfork always works, but has the signal mask problem. Catch 22?
Giga
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Change signal mask after vfork/clone system call
2010-11-04 15:37 ` Gregory Giguashvili
@ 2010-11-04 15:45 ` Alan Cox
2010-11-04 16:20 ` Gregory Giguashvili
0 siblings, 1 reply; 10+ messages in thread
From: Alan Cox @ 2010-11-04 15:45 UTC (permalink / raw)
To: Gregory Giguashvili; +Cc: linux-kernel
On Thu, 4 Nov 2010 15:37:05 +0000
Gregory Giguashvili <Gregory.Giguashvili@PDGM.com> wrote:
> > Fork on pretty much any Unix like system around today does copy-on-write
> >so while not as efficient as vfork should be fine for most purposes.
> Yes, but the problem is that fork simply does not work when a process has huge resident size and vm.overcommit_memory=0 as preferred by Linux distributions we run on. So, processes with large RSS footprint may occasionally fail fork, even if a tiny process is to be started.
>
> Using vfork always works, but has the signal mask problem. Catch 22?
And is there a reason you can't mask the signals, vfork and unmask them
again after the parent continues ?
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Change signal mask after vfork/clone system call
2010-11-04 15:45 ` Alan Cox
@ 2010-11-04 16:20 ` Gregory Giguashvili
2010-11-04 16:28 ` Alan Cox
0 siblings, 1 reply; 10+ messages in thread
From: Gregory Giguashvili @ 2010-11-04 16:20 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
> And is there a reason you can't mask the signals, vfork and unmask them
> again after the parent continues?
The signals are already masked in all threads and there's a dedicated thread, catching signals with sigwait. The problem is that vfork inherits signal mask to a child process and 3rd party executables are not processing any signals because they're not using sigwait technique.
Now, I could unmask signals for the thread calling vfork, but it seems not a signal-safe solution to me because signals may arrive to this thread until I reestablish the mask. pthread_atfork call comes to rescue to address such issues for fork, but there seems to be nothing for vfork call.
Giga
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Change signal mask after vfork/clone system call
2010-11-04 16:20 ` Gregory Giguashvili
@ 2010-11-04 16:28 ` Alan Cox
2010-11-04 16:43 ` Gregory Giguashvili
0 siblings, 1 reply; 10+ messages in thread
From: Alan Cox @ 2010-11-04 16:28 UTC (permalink / raw)
To: Gregory Giguashvili; +Cc: linux-kernel
> Now, I could unmask signals for the thread calling vfork, but it seems not a signal-safe solution to me because signals may arrive to this thread until I reestablish the mask. pthread_atfork call comes to rescue to address such issues for fork, but there seems to be nothing for vfork call.
Oh you are wrapping buggy apps ?
vfork
exec a tiny app which fixes the signals and execs the proper app
or fix the apps being run...
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Change signal mask after vfork/clone system call
2010-11-04 16:28 ` Alan Cox
@ 2010-11-04 16:43 ` Gregory Giguashvili
0 siblings, 0 replies; 10+ messages in thread
From: Gregory Giguashvili @ 2010-11-04 16:43 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
> Oh you are wrapping buggy apps ?
The applications are not buggy. They're just unaware of signals being blocked. It's a common practice to set a signal, but not to reset signal mask unfortunately.
> exec a tiny app which fixes the signals and execs the proper app
Yes, this is the last resort of course. I was wondering if I'm missing some functionality in Linux allowing me to avoid intermediate executables. It looks like I have to go via a wrapper exe.
Thank you for your comments,
Giga
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Change signal mask after vfork/clone system call
2010-11-04 9:48 ` Alan Cox
2010-11-04 15:37 ` Gregory Giguashvili
@ 2010-11-05 7:32 ` Gregory Giguashvili
1 sibling, 0 replies; 10+ messages in thread
From: Gregory Giguashvili @ 2010-11-05 7:32 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
> Finally, if using fork should be efficient for starting processes from applications with heavy VM/RSS memory footprint, > this question becomes obsolete.
What about posix_spawn API? It allows for resetting signal mask for the child process, but does it belong to fork or vfork "family"?
Giga
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-11-05 7:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-19 7:53 Change signal mask after vfork/clone system call Gregory Giguashvili
2010-10-20 7:56 ` Gregory Giguashvili
2010-11-04 6:08 ` Gregory Giguashvili
2010-11-04 9:48 ` Alan Cox
2010-11-04 15:37 ` Gregory Giguashvili
2010-11-04 15:45 ` Alan Cox
2010-11-04 16:20 ` Gregory Giguashvili
2010-11-04 16:28 ` Alan Cox
2010-11-04 16:43 ` Gregory Giguashvili
2010-11-05 7:32 ` Gregory Giguashvili
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®