From: Andy Lutomirski <firstname.lastname@example.org> To: Florian Weimer <email@example.com> Cc: Christian Brauner <firstname.lastname@example.org>, "Eric W. Biederman" <email@example.com>, LKML <firstname.lastname@example.org>, "Serge E. Hallyn" <email@example.com>, Jann Horn <firstname.lastname@example.org>, Andrew Lutomirski <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Oleg Nesterov <email@example.com>, Aleksa Sarai <firstname.lastname@example.org>, Al Viro <email@example.com>, Linux FS Devel <firstname.lastname@example.org>, Linux API <email@example.com>, Daniel Colascione <firstname.lastname@example.org>, Tim Murray <email@example.com>, linux-man <firstname.lastname@example.org>, Kees Cook <email@example.com> Subject: Re: [PATCH v2] signal: add procfd_signal() syscall Date: Thu, 6 Dec 2018 10:54:02 -0800 Message-ID: <CALCETrViXJ0gD34yVd8QpB-CSeKZzzncvkPHReycTiQin4r4WQ@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> > On Dec 4, 2018, at 4:55 AM, Florian Weimer <email@example.com> wrote: > > * Christian Brauner: > >>> On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote: >>> * Christian Brauner: >>> >>>> Ok, I finally have access to source code again. Scratch what I said above! >>>> I looked at the code and tested it. If the process has exited but not >>>> yet waited upon aka is a zombie procfd_send_signal() will return 0. This >>>> is identical to kill(2) behavior. It should've been sort-of obvious >>>> since when a process is in zombie state /proc/<pid> will still be around >>>> which means that struct pid must still be around. >>> >>> Should we make this state more accessible, by providing a different >>> error code? >> >> No, I don't think we want that. Imho, It's not really helpful. Signals >> are still delivered to zombies. If zombie state were to always mean that >> no-one is going to wait on this thread anymore then it would make sense >> to me. But given that zombie can also mean that someone put a >> sleep(1000) right before their wait() call in the parent it seems odd to >> report back that it is a zombie. > > It allows for error checking that the recipient of a signal is still > running. It's obviously not reliable, but I think it could be helpful > in the context of closely cooperating processes. > >>> Will the system call ever return ESRCH, given that you have a handle for >>> the process? >> >> Yes, whenever you signal a process that has already been waited upon: >> - get procfd handle referring to <proc> >> - <proc> exits and is waited upon >> - procfd_send_signal(procfd, ...) returns -1 with errno == ESRCH > > I see, thanks. > >>> Do you want to land all this in one kernel release? I wonder how >>> applications are supposed to discover kernel support if functionality is >>> split across several kernel releases. If you get EINVAL or EBADF, it >>> may not be obvious what is going on. >> >> Sigh, I get that but I really don't want to have to land this in one big >> chunk. I want this syscall to go in in a as soon as we can to fulfill >> the most basic need: having a way that guarantees us that we signal the >> process that we intended to signal. >> >> The thread case is easy to implement on top of it. But I suspect we will >> quibble about the exact semantics for a long time. Even now we have been >> on multiple - justified - detrous. That's all pefectly fine and >> expected. But if we have the basic functionality in we have time to do >> all of that. We might even land it in the same kernel release still. I >> really don't want to come of as tea-party-kernel-conservative here but I >> have time-and-time again seen that making something fancy and cover ever >> interesting feature in one patchset takes a very very long time. >> >> If you care about userspace being able to detect that case I can return >> EOPNOTSUPP when a tid descriptor is passed. > > I suppose that's fine. Or alternatively, when thread group support is > added, introduce a flag that applications have to use to enable it, so > that they can probe for support by checking support for the flag. > > I wouldn't be opposed to a new system call like this either: > > int procfd_open (pid_t thread_group, pid_t thread_id, unsigned flags); > > But I think this is frowned upon on the kernel side. I have no problem with it, except that I think it shouldn’t return an fd that can be used for proc filesystem access.
next prev parent reply index Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-20 10:51 Christian Brauner 2018-11-20 10:51 ` [PATCH v2] procfd_signal.2: document procfd_signal syscall Christian Brauner 2018-11-22 8:00 ` [PATCH v2] signal: add procfd_signal() syscall Serge E. Hallyn 2018-11-22 8:23 ` Aleksa Sarai 2018-11-28 14:05 ` Arnd Bergmann 2018-11-29 12:28 ` Florian Weimer 2018-11-29 16:54 ` Andy Lutomirski 2018-11-29 19:16 ` Christian Brauner 2018-11-29 19:22 ` Andy Lutomirski 2018-11-29 19:55 ` Christian Brauner 2018-11-29 20:14 ` Andy Lutomirski 2018-11-29 21:02 ` Arnd Bergmann 2018-11-29 21:35 ` Christian Brauner 2018-11-29 21:40 ` Arnd Bergmann 2018-11-30 2:40 ` Aleksa Sarai 2018-12-01 1:25 ` Christian Brauner 2018-11-30 5:13 ` Eric W. Biederman 2018-11-30 6:56 ` Christian Brauner 2018-11-30 11:41 ` Arnd Bergmann 2018-11-30 16:35 ` Andy Lutomirski 2018-11-30 21:57 ` Christian Brauner 2018-11-30 22:09 ` Arnd Bergmann 2018-11-30 22:26 ` Christian Brauner 2018-11-30 23:05 ` Daniel Colascione 2018-11-30 23:12 ` Arnd Bergmann 2018-11-30 23:15 ` Arnd Bergmann 2018-11-30 23:37 ` Christian Brauner 2018-11-30 23:46 ` Andy Lutomirski 2018-12-01 1:20 ` Christian Brauner 2018-11-30 23:53 ` Andy Lutomirski 2018-12-01 8:51 ` Arnd Bergmann 2018-12-01 9:17 ` Christian Brauner 2018-12-01 10:27 ` Arnd Bergmann 2018-12-01 13:41 ` Eric W. Biederman 2018-12-01 14:46 ` Eric W. Biederman 2018-12-01 15:28 ` Eric W. Biederman 2018-12-01 15:52 ` Andy Lutomirski 2018-12-01 16:27 ` Christian Brauner 2018-12-02 0:06 ` Eric W. Biederman 2018-12-02 1:14 ` Andy Lutomirski 2018-12-02 8:52 ` Christian Brauner 2018-11-30 23:52 ` Christian Brauner 2018-12-02 10:03 ` Christian Brauner 2018-12-03 16:57 ` Florian Weimer 2018-12-03 18:02 ` Christian Brauner 2018-12-04 6:03 ` Aleksa Sarai 2018-12-04 12:55 ` Florian Weimer 2018-12-04 13:26 ` Christian Brauner 2018-12-06 18:54 ` Andy Lutomirski [this message] 2018-12-06 18:56 ` Florian Weimer 2018-12-06 19:03 ` Christian Brauner 2018-12-25 5:32 ` Lai Jiangshan 2018-12-25 7:11 ` Lai Jiangshan 2018-12-25 12:07 ` Aleksa Sarai
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=CALCETrViXJ0gD34yVd8QpB-CSeKZzzncvkPHReycTiQin4r4WQ@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git