From: Oleg Nesterov <oleg@redhat.com>
To: Thiago Macieira <thiago.macieira@intel.com>
Cc: Josh Triplett <josh@joshtriplett.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Kees Cook <keescook@chromium.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>, Rik van Riel <riel@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Michael Kerrisk <mtk.manpages@gmail.com>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
linux-fsdevel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v2 5/7] clone4: Add a CLONE_AUTOREAP flag to automatically reap the child process
Date: Fri, 20 Mar 2015 20:09:14 +0100 [thread overview]
Message-ID: <20150320190914.GA28357@redhat.com> (raw)
In-Reply-To: <1766646.jusoNDOCPE@tjmaciei-mobl4>
On 03/20, Thiago Macieira wrote:
>
> On Friday 20 March 2015 19:14:04 Oleg Nesterov wrote:
> > Also. I forgot that the kernel always resets ->exit_signal to SIGCHLD on
> > exec or reparenting. Reparenting is probably fine. But what about exec?
> > Should it keep ->exit_signal == 0 if "autoreap" ? I think it should not, to
> > avoid the strange special case.
>
> Not delivering any signal was the objective of this patch series, so yes
> exit_signal == 0 should survive an exec and even re-exec.
OK, but then perhaps we should never send SIGCHLD (on exit) if "autoreap",
to make the logic simple.
And copy_process() should probably do
if ((clone_flags & CSIGNAL) && (clone_flags && CLONE_AUTOREAP))
return -EINVAL;
so that we still can change this behaviour later.
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Thiago Macieira
<thiago.macieira-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>,
Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"Paul E. McKenney"
<paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Michael Kerrisk
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v2 5/7] clone4: Add a CLONE_AUTOREAP flag to automatically reap the child process
Date: Fri, 20 Mar 2015 20:09:14 +0100 [thread overview]
Message-ID: <20150320190914.GA28357@redhat.com> (raw)
In-Reply-To: <1766646.jusoNDOCPE@tjmaciei-mobl4>
On 03/20, Thiago Macieira wrote:
>
> On Friday 20 March 2015 19:14:04 Oleg Nesterov wrote:
> > Also. I forgot that the kernel always resets ->exit_signal to SIGCHLD on
> > exec or reparenting. Reparenting is probably fine. But what about exec?
> > Should it keep ->exit_signal == 0 if "autoreap" ? I think it should not, to
> > avoid the strange special case.
>
> Not delivering any signal was the objective of this patch series, so yes
> exit_signal == 0 should survive an exec and even re-exec.
OK, but then perhaps we should never send SIGCHLD (on exit) if "autoreap",
to make the logic simple.
And copy_process() should probably do
if ((clone_flags & CSIGNAL) && (clone_flags && CLONE_AUTOREAP))
return -EINVAL;
so that we still can change this behaviour later.
Oleg.
next prev parent reply other threads:[~2015-03-20 19:11 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-15 7:59 [PATCH v2 0/7] CLONE_FD: Task exit notification via file descriptor Josh Triplett
2015-03-15 7:59 ` Josh Triplett
2015-03-15 7:59 ` [PATCH v2 1/7] clone: Support passing tls argument via C rather than pt_regs magic Josh Triplett
2015-03-15 7:59 ` [PATCH v2 2/7] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit Josh Triplett
2015-03-15 7:59 ` Josh Triplett
2015-03-15 7:59 ` [PATCH v2 3/7] Introduce a new clone4 syscall with more flag bits and extensible arguments Josh Triplett
2015-03-23 14:11 ` David Drysdale
2015-03-23 14:11 ` David Drysdale
2015-03-23 15:05 ` josh
2015-03-31 14:41 ` David Drysdale
2015-03-15 7:59 ` [PATCH v2 4/7] kernel/fork.c: Pass arguments to _do_fork and copy_process using clone4_args Josh Triplett
2015-03-15 8:00 ` [PATCH v2 5/7] clone4: Add a CLONE_AUTOREAP flag to automatically reap the child process Josh Triplett
2015-03-15 14:52 ` Oleg Nesterov
2015-03-15 14:52 ` Oleg Nesterov
2015-03-15 17:18 ` Josh Triplett
2015-03-15 17:18 ` Josh Triplett
2015-03-15 19:55 ` Oleg Nesterov
2015-03-15 19:55 ` Oleg Nesterov
2015-03-15 23:34 ` Josh Triplett
2015-03-15 23:34 ` Josh Triplett
2015-03-20 18:14 ` Oleg Nesterov
2015-03-20 18:46 ` Thiago Macieira
2015-03-20 19:09 ` Oleg Nesterov [this message]
2015-03-20 19:09 ` Oleg Nesterov
2015-03-20 21:10 ` josh
2015-03-15 8:00 ` [PATCH v2 6/7] signal: Factor out a helper function to process task_struct exit_code Josh Triplett
2015-03-15 8:00 ` [PATCH v2 7/7] clone4: Add a CLONE_FD flag to get task exit notification via fd Josh Triplett
2015-03-23 17:38 ` David Drysdale
2015-03-25 14:53 ` Josh Triplett
2015-04-06 8:30 ` Sergey Senozhatsky
2015-04-06 8:30 ` Sergey Senozhatsky
2015-04-06 9:31 ` Josh Triplett
2015-04-06 9:31 ` Josh Triplett
2015-03-15 8:00 ` [PATCH v2 man-pages] clone4.2: New manpage documenting clone4(2) Josh Triplett
2015-03-15 8:04 ` [PATCH v2 0/7] CLONE_FD: Task exit notification via file descriptor Josh Triplett
2015-03-15 8:04 ` Josh Triplett
2015-03-16 21:44 ` Kees Cook
2015-03-16 21:44 ` Kees Cook
2015-03-16 22:14 ` Thiago Macieira
2015-03-16 22:14 ` Thiago Macieira
2015-03-16 22:36 ` Kees Cook
2015-03-16 22:50 ` Thiago Macieira
2015-03-16 22:50 ` Thiago Macieira
2015-03-16 23:26 ` Kees Cook
2015-03-16 23:35 ` josh
2015-03-16 23:29 ` josh
2015-03-16 23:29 ` josh-iaAMLnmF4UmaiuxdJuQwMA
2015-03-17 0:49 ` Thiago Macieira
2015-03-17 0:49 ` Thiago Macieira
2015-03-23 14:12 ` David Drysdale
2015-03-23 15:03 ` josh
2015-03-16 23:25 ` josh
2015-03-16 23:25 ` josh-iaAMLnmF4UmaiuxdJuQwMA
2015-03-31 20:08 ` Jonathan Corbet
2015-03-31 22:02 ` josh
2015-04-01 7:24 ` Jonathan Corbet
2015-04-09 2:19 ` Josh Triplett
2015-04-09 2:19 ` Josh Triplett
2015-05-29 7:43 ` Florian Weimer
2015-05-29 7:43 ` Florian Weimer
2015-05-29 20:27 ` Thiago Macieira
2015-06-15 10:06 ` Florian Weimer
2015-06-15 10:06 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150320190914.GA28357@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=mtk.manpages@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=thiago.macieira@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.