linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aleksa Sarai <cyphar@cyphar.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	"Jürg Billeter" <j@bitron.ch>,
	"Christian Brauner" <christian@brauner.io>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	luto@kernel.org, arnd@arndb.de, serge@hallyn.com,
	jannh@google.com, akpm@linux-foundation.org, oleg@redhat.com,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
	dancol@google.com, timmurray@google.com,
	linux-man@vger.kernel.org, keescook@chromium.org,
	tglx@linutronix.de, x86@kernel.org
Subject: Re: [PATCH v4] signal: add taskfd_send_signal() syscall
Date: Fri, 7 Dec 2018 01:27:57 +1100	[thread overview]
Message-ID: <20181206142757.4gon5afqd7uphyqk@yavin> (raw)
In-Reply-To: <877egm6a7v.fsf@oldenburg2.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

On 2018-12-06, Florian Weimer <fweimer@redhat.com> wrote:
> > Floriam are you seeing a problem with this behavior or the way Christian
> > was describing it?
> 
> My hope is that you could use taskfd_send_signal one day to send a
> signal to a process which you *known* (based on how you've written your
> application) should be running and not in a zombie state, and get back
> an error if it has exited.

You can detect if a process is a zombie via the procfd by observing "stat"
(the state will be "Z"). Personally I'm with Christian that we should
maintain compatibility with the rest of the signal APIs -- sending a
signal to a zombie is a defined (though no-op) concept.

I don't understand why sending a signal should fail in this case -- a
zombie is not the same as a non-existent process. If we need to have a
way of checking whether something is a zombie (other than through
"stat") we can add another method (or flag if it has to be atomic) in
the future. And given the complexity of doing it, I'm even less of a
fan of doing it in the initial patchset.

> If you get this error, only then you wait on the process, using the file
> descriptor you have, and run some recovery code.
> 
> Wouldn't that be a reasonable approach once we've got task descriptors?

I think taskfd_wait() is something we'll need eventually, but I don't
think that making taskfd_send_signal() do something that is contrary to
existing kill(2) interfaces (making it so that transitioning to it won't
be seamless), 

What would the error be? ESRCH would be _very_ wrong, given that it
would confuse the two states (zombie/dead-for-real) and would lead to
weird cases where fstatat(taskfd) succeeds but taskfd_send_signal(2)
fails.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-12-06 14:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 12:18 [PATCH v4] signal: add taskfd_send_signal() syscall Christian Brauner
2018-12-06 12:30 ` Florian Weimer
2018-12-06 12:45   ` Jürg Billeter
2018-12-06 13:12     ` Florian Weimer
2018-12-06 13:18       ` Jürg Billeter
2018-12-06 13:20         ` Florian Weimer
2018-12-06 13:40       ` Eric W. Biederman
2018-12-06 13:44         ` Florian Weimer
2018-12-06 14:27           ` Aleksa Sarai [this message]
2018-12-06 14:46           ` Eric W. Biederman
2018-12-06 12:53   ` Christian Brauner
2018-12-06 13:17     ` Florian Weimer
2018-12-06 15:01 ` Eric W. Biederman
2018-12-06 16:17   ` Daniel Colascione
2018-12-06 17:24     ` Eric W. Biederman
2018-12-06 17:41       ` Christian Brauner
2018-12-06 18:30         ` Kees Cook
2018-12-06 22:27           ` Serge E. Hallyn
2018-12-06 17:14   ` Christian Brauner
2018-12-06 19:17     ` Eric W. Biederman
2018-12-06 19:30       ` Christian Brauner
2018-12-06 20:29         ` Eric W. Biederman
2018-12-06 20:37           ` Daniel Colascione
2018-12-06 22:22             ` Eric W. Biederman
2018-12-06 22:43               ` Daniel Colascione
2018-12-06 21:31           ` Christian Brauner
2018-12-06 21:46             ` Eric W. Biederman
2018-12-06 22:01               ` Daniel Colascione
2018-12-06 22:39               ` Christian Brauner
2018-12-06 23:17                 ` Christian Brauner
2018-12-07  0:31                   ` Serge E. Hallyn
2018-12-07  0:34                     ` Daniel Colascione
2018-12-07  0:59                       ` Serge E. Hallyn
2018-12-07  1:39                         ` Daniel Colascione
2018-12-07  1:54                           ` Christian Brauner
2018-12-07 16:49                             ` Serge E. Hallyn
2018-12-07 16:47 ` Serge E. Hallyn
2018-12-08 21:46 ` kbuild test robot

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=20181206142757.4gon5afqd7uphyqk@yavin \
    --to=cyphar@cyphar.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=christian@brauner.io \
    --cc=dancol@google.com \
    --cc=ebiederm@xmission.com \
    --cc=fweimer@redhat.com \
    --cc=j@bitron.ch \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=oleg@redhat.com \
    --cc=serge@hallyn.com \
    --cc=tglx@linutronix.de \
    --cc=timmurray@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).