From: Oleg Nesterov <oleg@redhat.com>
To: "Jürg Billeter" <j@bitron.ch>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Eric Biederman <ebiederm@xmission.com>,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] prctl: add PR_[GS]ET_KILLABLE
Date: Wed, 1 Aug 2018 16:19:15 +0200 [thread overview]
Message-ID: <20180801141914.GA21248@redhat.com> (raw)
In-Reply-To: <f21a22c9730ab455504f58a5fbda72cba0eb1227.camel@bitron.ch>
On 07/31, Jürg Billeter wrote:
>
> > Could you explain your use-case? Why a shell wants to use
> > CLONE_NEWPID?
>
> To guarantee that there won't be any runaway processes, i.e., ensure
> that no descendants (background helper daemons or misbehaving
> processes) survive when the child process is terminated.
We already have PR_SET_CHILD_SUBREAPER.
Perhaps we can finally add PR_KILL_MY_DESCENDANTS_ON_EXIT? This was already
discussed some time ago, but I can't find the previous discussion... Simple
to implement.
> And to prevent
> children from killing their ancestors.
OK, this is the only reason for CLONE_NEWPID which I can understand so far.
Not that I understand why this is that useful ;)
> > > * As SIGSTOP is ignored when raised from the SIGNAL_UNKILLABLE process
> > > itself, it's not possible to implement the stop action in a custom
> > > SIGTSTP handler.
> >
> > Yes. So may be we actually want to change __isig() paths to use
> > SEND_SIG_FORCED (this is not that simple), or perhaps we can change
> > __send_signal() to not drop SIGSTOP sent to itself, or may be we can even
> > introduce SIG_DFL_EVEN_IF_INIT, I dunno.
>
> In my opinion, my patch is much simpler and also more general as it
Yes, yes, let me repeat that I am not arguing with your patch, I am just trying
to understand what
> > I can't understand this. An application should be changed anyway to do
> > PR_SET_KILLABLE?
>
> PR_SET_KILLABLE can be called (e.g., by the shell) between clone() and
> execve().
OK, this is true.
Oleg.
next prev parent reply other threads:[~2018-08-01 14:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 7:52 [PATCH] prctl: add PR_[GS]ET_KILLABLE Jürg Billeter
2018-07-30 10:17 ` Oleg Nesterov
2018-07-30 19:32 ` Jürg Billeter
2018-07-30 19:39 ` Thomas Gleixner
2018-07-31 7:03 ` [PATCH v2] " Jürg Billeter
2018-07-31 14:39 ` Oleg Nesterov
2018-07-31 16:12 ` Jürg Billeter
2018-08-01 14:19 ` Oleg Nesterov [this message]
2018-08-03 10:15 ` Jürg Billeter
2018-08-03 12:14 ` Oleg Nesterov
2018-08-03 13:34 ` Eric W. Biederman
2018-08-03 13:34 ` Eric W. Biederman
2018-08-03 14:39 ` Jürg Billeter
2018-07-31 16:26 ` [PATCH] " Jann Horn
2018-08-01 7:43 ` Jürg Billeter
2018-08-01 7:56 ` Jann Horn
2018-08-03 14:40 ` [PATCH v3 1/2] fork: do not rely on SIGNAL_UNKILLABLE for init check Jürg Billeter
2018-08-03 14:40 ` [PATCH v3 2/2] prctl: add PR_[GS]ET_KILLABLE Jürg Billeter
2018-09-06 22:42 ` Andrew Morton
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=20180801141914.GA21248@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=j@bitron.ch \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.