Re: KASAN: use-after-free Read in userfaultfd_release (2)

2020-07-20 Thread Daniel Colascione
On 7/20/20 9:00 AM, Al Viro wrote: On Mon, Jul 13, 2020 at 04:45:12PM +0800, Hillf Danton wrote: Bridge the gap between slab free and the fput in task work wrt file's private data. No. This @@ -2048,6 +2055,7 @@ SYSCALL_DEFINE1(userfaultfd, int, flags) fd =

Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.

2019-10-22 Thread Daniel Colascione
On Sat, Oct 12, 2019 at 6:14 PM Andy Lutomirski wrote: > [adding more people because this is going to be an ABI break, sigh] Just pinging this thread. I'd like to rev my patch and I'm not sure what we want to do about problem Andy identified. Are we removing UFFD_EVENT_FORK?

Re: [PATCH 1/7] Add a new flags-accepting interface for anonymous inodes

2019-10-14 Thread Daniel Colascione
Thanks for taking a look On Mon, Oct 14, 2019 at 8:39 AM Jann Horn wrote: > > On Sat, Oct 12, 2019 at 9:16 PM Daniel Colascione wrote: > > Add functions forwarding from the old names to the new ones so we > > don't need to change any callers. > > This patch does more

Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.

2019-10-12 Thread Daniel Colascione
On Sat, Oct 12, 2019 at 6:14 PM Andy Lutomirski wrote: > .. > > > But maybe we can go further: let's separate authentication and > > authorization, as we do in other LSM hooks. Let's split my > > inode_init_security_anon into two hooks, inode_init_security_anon and > > inode_create_anon. We'd

Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.

2019-10-12 Thread Daniel Colascione
On Sat, Oct 12, 2019 at 4:10 PM Andy Lutomirski wrote: > > On Sat, Oct 12, 2019 at 12:16 PM Daniel Colascione wrote: > > > > The new secure flag makes userfaultfd use a new "secure" anonymous > > file object instead of the default one, letting security mod

Re: [PATCH 4/7] Teach SELinux about a new userfaultfd class

2019-10-12 Thread Daniel Colascione
On Sat, Oct 12, 2019 at 4:09 PM Andy Lutomirski wrote: > > On Sat, Oct 12, 2019 at 12:16 PM Daniel Colascione wrote: > > > > Use the secure anonymous inode LSM hook we just added to let SELinux > > policy place restrictions on userfaultfd use. The create operation

[PATCH 7/7] Add a new sysctl for limiting userfaultfd to user mode faults

2019-10-12 Thread Daniel Colascione
-off-by: Daniel Colascione --- Documentation/admin-guide/sysctl/vm.rst | 13 + fs/userfaultfd.c| 12 ++-- include/linux/userfaultfd_k.h | 1 + kernel/sysctl.c | 9 + 4 files changed, 33 insertions(+), 2

[PATCH 6/7] Allow users to require UFFD_SECURE

2019-10-12 Thread Daniel Colascione
to userfaultfd in order for the system call to succeed, effectively forcing them to opt into additional security checks. Signed-off-by: Daniel Colascione --- Documentation/admin-guide/sysctl/vm.rst | 6 -- fs/userfaultfd.c| 4 +++- kernel/sysctl.c | 2

[PATCH 4/7] Teach SELinux about a new userfaultfd class

2019-10-12 Thread Daniel Colascione
checked inside selinux_file_receive. Signed-off-by: Daniel Colascione --- fs/userfaultfd.c| 4 +- include/linux/userfaultfd_k.h | 2 + security/selinux/hooks.c| 68 + security/selinux/include/classmap.h | 2 + 4 files changed

[PATCH 2/7] Add a concept of a "secure" anonymous file

2019-10-12 Thread Daniel Colascione
to interact with non-secure anonymous files due to all of these files sharing a single inode. Signed-off-by: Daniel Colascione --- fs/anon_inodes.c | 45 ++- include/linux/lsm_hooks.h | 8 +++ include/linux/security.h | 2 ++ security/security.c

[PATCH 1/7] Add a new flags-accepting interface for anonymous inodes

2019-10-12 Thread Daniel Colascione
Add functions forwarding from the old names to the new ones so we don't need to change any callers. Signed-off-by: Daniel Colascione --- fs/anon_inodes.c| 62 ++--- include/linux/anon_inodes.h | 27 +--- 2 files changed, 59 insertions

[PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.

2019-10-12 Thread Daniel Colascione
The new secure flag makes userfaultfd use a new "secure" anonymous file object instead of the default one, letting security modules supervise userfaultfd use. Requiring that users pass a new flag lets us avoid changing the semantics for existing callers. Signed-off-by: Daniel Colascion

[PATCH 0/7] Harden userfaultfd

2019-10-12 Thread Daniel Colascione
inodes for anonymous file objects instead of reusing a singleton dummy inode. A new LSM hook gives security modules an opportunity to configure and veto these ephemeral inodes. Existing anon_inodes users must opt into the new functionality. Daniel Colascione (7): Add a new flags-accepting

[PATCH 5/7] Let userfaultfd opt out of handling kernel-mode faults

2019-10-12 Thread Daniel Colascione
for future exploits. Signed-off-by: Daniel Colascione --- fs/userfaultfd.c | 5 - include/uapi/linux/userfaultfd.h | 6 ++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 1123089c3d55..986d23b2cd33 100644 --- a/fs

Re: [PATCH] Make SPLIT_RSS_COUNTING configurable

2019-10-04 Thread Daniel Colascione
On Fri, Oct 4, 2019 at 6:26 AM Kirill A. Shutemov wrote: > On Fri, Oct 04, 2019 at 02:33:49PM +0200, Michal Hocko wrote: > > On Wed 02-10-19 19:08:16, Daniel Colascione wrote: > > > On Wed, Oct 2, 2019 at 6:56 PM Qian Cai wrote: > > > > > On Oct 2, 20

Re: [PATCH] Make SPLIT_RSS_COUNTING configurable

2019-10-02 Thread Daniel Colascione
On Wed, Oct 2, 2019 at 6:56 PM Qian Cai wrote: > > On Oct 2, 2019, at 4:29 PM, Daniel Colascione wrote: > > > > Adding the correct linux-mm address. > > > > > >> On Wed, Oct 2, 2019 at 1:25 PM Daniel Colascione wrote: > >> > >> Using th

Re: [PATCH] Make SPLIT_RSS_COUNTING configurable

2019-10-02 Thread Daniel Colascione
Adding the correct linux-mm address. On Wed, Oct 2, 2019 at 1:25 PM Daniel Colascione wrote: > > Using the new config option, users can disable SPLIT_RSS_COUNTING to > get increased accuracy in user-visible mm counters. > > Signed-off-by: Daniel Colascione > --- >

[PATCH] Make SPLIT_RSS_COUNTING configurable

2019-10-02 Thread Daniel Colascione
Using the new config option, users can disable SPLIT_RSS_COUNTING to get increased accuracy in user-visible mm counters. Signed-off-by: Daniel Colascione --- include/linux/mm.h| 4 ++-- include/linux/mm_types_task.h | 5 ++--- include/linux/sched.h | 2 +- kernel/fork.c

Re: For review: pidfd_send_signal(2) manual page

2019-09-24 Thread Daniel Colascione
On Tue, Sep 24, 2019 at 2:00 PM Michael Kerrisk (man-pages) wrote: > > Hello Christian, > > >>> If you're the parent of the process you can do this without CLONE_PIDFD: > >>> pid = fork(); > >>> pidfd = pidfd_open(); > >>> ret = pidfd_send_signal(pidfd, 0, NULL, 0); > >>> if (ret < 0 && errno ==

Re: For review: pidfd_send_signal(2) manual page

2019-09-23 Thread Daniel Colascione
On Mon, Sep 23, 2019 at 2:12 AM Michael Kerrisk (man-pages) wrote: >The pidfd_send_signal() system call allows the avoidance of race >conditions that occur when using traditional interfaces (such as >kill(2)) to signal a process. The problem is that the traditional >

Re: For review: pidfd_open(2) manual page

2019-09-23 Thread Daniel Colascione
On Mon, Sep 23, 2019 at 3:53 AM Florian Weimer wrote: > > * Michael Kerrisk: > > > SYNOPSIS > >int pidfd_open(pid_t pid, unsigned int flags); > > Should this mention for pid_t? > > > ERRORS > >EINVAL flags is not 0. > > > >EINVAL pid is not valid. > > > >ESRCH

Re: [RFC] Add critical process prctl

2019-09-10 Thread Daniel Colascione
On Tue, Sep 10, 2019 at 9:57 AM Andy Lutomirski wrote: > > On Wed, Sep 4, 2019 at 5:53 PM Daniel Colascione wrote: > > > > A task with CAP_SYS_ADMIN can mark itself PR_SET_TASK_CRITICAL, > > meaning that if the task ever exits, the kernel panics. This facility > &

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-05 Thread Daniel Colascione
On Thu, Sep 5, 2019 at 5:59 PM Joel Fernandes wrote: > On Thu, Sep 05, 2019 at 10:50:27AM -0700, Daniel Colascione wrote: > > On Thu, Sep 5, 2019 at 10:35 AM Steven Rostedt wrote: > > > On Thu, 5 Sep 2019 09:03:01 -0700 > > > Suren Baghdasaryan wrote: > > >

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-05 Thread Daniel Colascione
On Thu, Sep 5, 2019 at 3:12 PM Daniel Colascione wrote: > Basically, what I have in mind is this: Actually --- I wonder whether there's already enough power in the trigger mechanism to do this without any code changes to ftrace histograms themselves. I'm trying to think of the minimum additio

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-05 Thread Daniel Colascione
On Thu, Sep 5, 2019 at 2:14 PM Tom Zanussi wrote: > > On Thu, 2019-09-05 at 13:24 -0700, Daniel Colascione wrote: > > On Thu, Sep 5, 2019 at 12:56 PM Tom Zanussi > > wrote: > > > On Thu, 2019-09-05 at 13:51 -0400, Joel Fernandes wrote: > > > > On Thu,

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-05 Thread Daniel Colascione
On Thu, Sep 5, 2019 at 12:56 PM Tom Zanussi wrote: > On Thu, 2019-09-05 at 13:51 -0400, Joel Fernandes wrote: > > On Thu, Sep 05, 2019 at 01:47:05PM -0400, Joel Fernandes wrote: > > > On Thu, Sep 05, 2019 at 01:35:07PM -0400, Steven Rostedt wrote: > > > > > > > > > > > > [ Added Tom ] > > > > > >

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-05 Thread Daniel Colascione
On Thu, Sep 5, 2019 at 10:35 AM Steven Rostedt wrote: > On Thu, 5 Sep 2019 09:03:01 -0700 > Suren Baghdasaryan wrote: > > > On Thu, Sep 5, 2019 at 7:43 AM Michal Hocko wrote: > > > > > > [Add Steven] > > > > > > On Wed 04-09-19 12:28:08, Joel Fernandes wrote: > > > > On Wed, Sep 4, 2019 at

[RFC] Add critical process prctl

2019-09-04 Thread Daniel Colascione
restarts when they die regardless of whether the rest of userspace is operational. Signed-off-by: Daniel Colascione --- include/linux/sched.h | 5 + include/uapi/linux/prctl.h | 5 + kernel/exit.c | 2 ++ kernel/sys.c | 19 +++ 4 files

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-04 Thread Daniel Colascione
On Wed, Sep 4, 2019 at 8:38 AM Michal Hocko wrote: > > but also for reducing > > tracing noise. Flooding the traces makes it less useful for long traces and > > post-processing of traces. IOW, the overhead reduction is a bonus. > > This is not really anything special for this tracepoint though. >

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-04 Thread Daniel Colascione
On Wed, Sep 4, 2019 at 7:59 AM Joel Fernandes wrote: > > On Tue, Sep 03, 2019 at 10:42:53PM -0700, Daniel Colascione wrote: > > On Tue, Sep 3, 2019 at 10:15 PM Joel Fernandes > > wrote: > > > > > > On Tue, Sep 03, 2019 at 09:51:20PM -0700, Daniel Colascion

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-03 Thread Daniel Colascione
On Tue, Sep 3, 2019 at 10:15 PM Joel Fernandes wrote: > > On Tue, Sep 03, 2019 at 09:51:20PM -0700, Daniel Colascione wrote: > > On Tue, Sep 3, 2019 at 9:45 PM Suren Baghdasaryan wrote: > > > > > > On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google) > &

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

2019-09-03 Thread Daniel Colascione
On Tue, Sep 3, 2019 at 9:45 PM Suren Baghdasaryan wrote: > > On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google) > wrote: > > > > Useful to track how RSS is changing per TGID to detect spikes in RSS and > > memory hogs. Several Android teams have been using this patch in various > > kernel

Re: [RFCv2 1/6] mm: introduce MADV_COLD

2019-06-03 Thread Daniel Colascione
On Mon, Jun 3, 2019 at 12:16 AM Michal Hocko wrote: > On Fri 31-05-19 23:34:07, Minchan Kim wrote: > > On Fri, May 31, 2019 at 04:03:32PM +0200, Michal Hocko wrote: > > > On Fri 31-05-19 22:39:04, Minchan Kim wrote: > > > > On Fri, May 31, 2019 at 10:47:52AM +0200, Michal Hocko wrote: > > > > >

Re: [RFCv2 5/6] mm: introduce external memory hinting API

2019-05-31 Thread Daniel Colascione
On Thu, May 30, 2019 at 11:43 PM Minchan Kim wrote: > > There is some usecase that centralized userspace daemon want to give > a memory hint like MADV_[COLD|PAGEEOUT] to other process. Android's > ActivityManagerService is one of them. > > It's similar in spirit to madvise(MADV_WONTNEED), but the

Re: [RFC 6/7] mm: extend process_madvise syscall to support vector arrary

2019-05-30 Thread Daniel Colascione
On Thu, May 30, 2019 at 1:02 AM Minchan Kim wrote: > > On Thu, May 30, 2019 at 08:57:55AM +0200, Michal Hocko wrote: > > On Thu 30-05-19 11:17:48, Minchan Kim wrote: > > > On Wed, May 29, 2019 at 12:33:52PM +0200, Michal Hocko wrote: > > > > On Wed 29-05-19

Re: [RFC 6/7] mm: extend process_madvise syscall to support vector arrary

2019-05-29 Thread Daniel Colascione
On Mon, May 27, 2019 at 12:49 AM Minchan Kim wrote: > > On Tue, May 21, 2019 at 12:37:26PM +0200, Michal Hocko wrote: > > On Tue 21-05-19 19:26:13, Minchan Kim wrote: > > > On Tue, May 21, 2019 at 08:24:21AM +0200, Michal Hocko wrote: > > > > On Tue 21-05-19 11:48:20, Minchan Kim wrote: > > > > >

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
On Tue, May 28, 2019 at 4:56 AM Michal Hocko wrote: > > On Tue 28-05-19 04:42:47, Daniel Colascione wrote: > > On Tue, May 28, 2019 at 4:28 AM Michal Hocko wrote: > > > > > > On Tue 28-05-19 20:12:08, Minchan Kim wrote: > > > > On Tue, May 28, 20

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
On Tue, May 28, 2019 at 4:49 AM Michal Hocko wrote: > > On Tue 28-05-19 04:21:44, Daniel Colascione wrote: > > On Tue, May 28, 2019 at 3:33 AM Michal Hocko wrote: > > > > > > On Tue 28-05-19 02:39:03, Daniel Colascione wrote: > > > > On Tue, M

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
05-19 19:32:56, Minchan Kim wrote: > > > > > On Tue, May 28, 2019 at 11:08:21AM +0200, Michal Hocko wrote: > > > > > > On Tue 28-05-19 17:49:27, Minchan Kim wrote: > > > > > > > On Tue, May 28, 2019 at 01:31:13AM -0700, Daniel Colascione wro

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
08:21AM +0200, Michal Hocko wrote: > > > > > On Tue 28-05-19 17:49:27, Minchan Kim wrote: > > > > > > On Tue, May 28, 2019 at 01:31:13AM -0700, Daniel Colascione wrote: > > > > > > > On Tue, May 28, 2019 at 1:14 AM Minchan Kim > >

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
On Tue, May 28, 2019 at 3:41 AM Michal Hocko wrote: > > On Tue 28-05-19 19:32:56, Minchan Kim wrote: > > On Tue, May 28, 2019 at 11:08:21AM +0200, Michal Hocko wrote: > > > On Tue 28-05-19 17:49:27, Minchan Kim wrote: > > > > On Tue, May 28, 2019 at 01:31:13

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
On Tue, May 28, 2019 at 3:33 AM Michal Hocko wrote: > > On Tue 28-05-19 02:39:03, Daniel Colascione wrote: > > On Tue, May 28, 2019 at 2:08 AM Michal Hocko wrote: > > > > > > On Tue 28-05-19 17:49:27, Minchan Kim wrote: > > > > On Tue, May 28, 2019 at

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
On Tue, May 28, 2019 at 2:08 AM Michal Hocko wrote: > > On Tue 28-05-19 17:49:27, Minchan Kim wrote: > > On Tue, May 28, 2019 at 01:31:13AM -0700, Daniel Colascione wrote: > > > On Tue, May 28, 2019 at 1:14 AM Minchan Kim wrote: > > > > if we went with the per v

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-28 Thread Daniel Colascione
On Tue, May 28, 2019 at 1:14 AM Minchan Kim wrote: > if we went with the per vma fd approach then you would get this > > feature automatically because map_files would refer to file backed > > mappings while map_anon could refer only to anonymous mappings. > > The reason to add such filter option

Re: [RFC 0/7] introduce memory hinting API for external process

2019-05-22 Thread Daniel Colascione
On Wed, May 22, 2019 at 9:01 AM Christian Brauner wrote: > > On Wed, May 22, 2019 at 08:57:47AM -0700, Daniel Colascione wrote: > > On Wed, May 22, 2019 at 8:48 AM Christian Brauner > > wrote: > > > > > > On Wed, May 22, 2019 at 08:17:23AM -0700, Daniel Cola

Re: [RFC 0/7] introduce memory hinting API for external process

2019-05-22 Thread Daniel Colascione
On Wed, May 22, 2019 at 8:48 AM Christian Brauner wrote: > > On Wed, May 22, 2019 at 08:17:23AM -0700, Daniel Colascione wrote: > > On Wed, May 22, 2019 at 7:52 AM Christian Brauner > > wrote: > > > I'm not going to go into yet another long argument. I prefer pidf

Re: [RFC 0/7] introduce memory hinting API for external process

2019-05-22 Thread Daniel Colascione
On Wed, May 22, 2019 at 7:52 AM Christian Brauner wrote: > I'm not going to go into yet another long argument. I prefer pidfd_*. Ok. We're each allowed our opinion. > It's tied to the api, transparent for userspace, and disambiguates it > from process_vm_{read,write}v that both take a pid_t.

Re: [RFC 0/7] introduce memory hinting API for external process

2019-05-22 Thread Daniel Colascione
On Wed, May 22, 2019 at 1:22 AM Christian Brauner wrote: > > On Wed, May 22, 2019 at 7:12 AM Daniel Colascione wrote: > > > > On Tue, May 21, 2019 at 4:39 AM Christian Brauner > > wrote: > > > > > > On Tue, May 21, 2019 at 01:30:29PM +0200, Christian B

Re: [RFC 0/7] introduce memory hinting API for external process

2019-05-21 Thread Daniel Colascione
On Tue, May 21, 2019 at 4:39 AM Christian Brauner wrote: > > On Tue, May 21, 2019 at 01:30:29PM +0200, Christian Brauner wrote: > > On Tue, May 21, 2019 at 08:05:52PM +0900, Minchan Kim wrote: > > > On Tue, May 21, 2019 at 10:42:00AM +0200, Christian Brauner wrote: > > > > On Mon, May 20, 2019 at

Re: [PATCH v1 2/2] Add selftests for pidfd polling

2019-04-26 Thread Daniel Colascione
On Fri, Apr 26, 2019 at 10:26 AM Joel Fernandes wrote: > On Thu, Apr 25, 2019 at 03:07:48PM -0700, Daniel Colascione wrote: > > On Thu, Apr 25, 2019 at 2:29 PM Christian Brauner > > wrote: > > > This timing-based testing seems kinda odd to be honest. Can't we do >

Re: [PATCH v1 2/2] Add selftests for pidfd polling

2019-04-25 Thread Daniel Colascione
On Thu, Apr 25, 2019 at 2:29 PM Christian Brauner wrote: > This timing-based testing seems kinda odd to be honest. Can't we do > something better than this? Agreed. Timing-based tests have a substantial risk of becoming flaky. We ought to be able to make these tests fully deterministic and not

Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

2019-04-20 Thread Daniel Colascione
On Sat, Apr 20, 2019 at 12:14 AM Kevin Easton wrote: > On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote: > > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote: > > > > > > On 2019-04-15, Enrico Weigelt, metux IT consult wrote: > > > > > This patchset makes it possible to

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 4:12 PM Christian Brauner wrote: > > On Sat, Apr 20, 2019 at 12:46 AM Daniel Colascione wrote: > > > > On Fri, Apr 19, 2019 at 3:02 PM Christian Brauner > > wrote: > > > > > > On Fri, Apr 19, 2019 at 11:48 PM Christian Brauner

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 4:33 PM Linus Torvalds wrote: > > On Fri, Apr 19, 2019 at 4:20 PM Christian Brauner > wrote: > > > > On Sat, Apr 20, 2019 at 1:11 AM Linus Torvalds > > wrote: > > > > > > It's also worth noting that POLLERR/POLLHUP/POLLNVAL cannot be masked > > > for "poll()". Even if

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 4:02 PM Christian Brauner wrote: > > On Sat, Apr 20, 2019 at 12:35 AM Daniel Colascione wrote: > > > > On Fri, Apr 19, 2019 at 2:48 PM Christian Brauner > > wrote: > > > > > > On Fri, Apr 19, 2019 at 11:21 PM Daniel Colascione

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 3:02 PM Christian Brauner wrote: > > On Fri, Apr 19, 2019 at 11:48 PM Christian Brauner > wrote: > > > > On Fri, Apr 19, 2019 at 11:21 PM Daniel Colascione > > wrote: > > > > > > On Fri, Apr 19, 2019 at 1:57 PM Christian

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 3:18 PM Christian Brauner wrote: > > On Sat, Apr 20, 2019 at 12:08 AM Daniel Colascione wrote: > > > > On Fri, Apr 19, 2019 at 2:45 PM Joel Fernandes > > wrote: > > > > > > On Fri, Apr 19, 2019 at 02:24:09PM -0700, Daniel Cola

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 2:48 PM Christian Brauner wrote: > > On Fri, Apr 19, 2019 at 11:21 PM Daniel Colascione wrote: > > > > On Fri, Apr 19, 2019 at 1:57 PM Christian Brauner > > wrote: > > > > > > On Fri, Apr 19, 2019 at 10:34 PM Daniel Colascione

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 2:45 PM Joel Fernandes wrote: > > On Fri, Apr 19, 2019 at 02:24:09PM -0700, Daniel Colascione wrote: > > On Fri, Apr 19, 2019 at 2:20 PM Joel Fernandes > > wrote: > > > > > > On Fri, Apr 19, 2019 at 10:57:11PM +0200, Christian Brauner

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 2:20 PM Joel Fernandes wrote: > > On Fri, Apr 19, 2019 at 10:57:11PM +0200, Christian Brauner wrote: > > On Fri, Apr 19, 2019 at 10:34 PM Daniel Colascione > > wrote: > > > > > > On Fri, Apr 19, 2019 at 12:49 PM Joel Fernandes >

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 1:57 PM Christian Brauner wrote: > > On Fri, Apr 19, 2019 at 10:34 PM Daniel Colascione wrote: > > > > On Fri, Apr 19, 2019 at 12:49 PM Joel Fernandes > > wrote: > > > > > > On Fri, Apr 19, 2019 at 09:18:59PM +0200, Christian B

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-19 Thread Daniel Colascione
On Fri, Apr 19, 2019 at 12:49 PM Joel Fernandes wrote: > > On Fri, Apr 19, 2019 at 09:18:59PM +0200, Christian Brauner wrote: > > On Fri, Apr 19, 2019 at 03:02:47PM -0400, Joel Fernandes wrote: > > > On Thu, Apr 18, 2019 at 07:26:44PM +0200, Christian Brauner wrote: > > > > On April 18, 2019

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-18 Thread Daniel Colascione
On Thu, Apr 18, 2019 at 11:44 AM Jonathan Kowalski wrote: > > On Tue, Apr 16, 2019 at 8:21 PM Joel Fernandes wrote: > > > > On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote: > > > On 04/11, Joel Fernandes (Google) wrote: > > > > > > > > +static unsigned int

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-18 Thread Daniel Colascione
On Thu, Apr 18, 2019 at 10:26 AM Christian Brauner wrote: > > On April 18, 2019 7:23:38 PM GMT+02:00, Jann Horn wrote: > >On Wed, Apr 17, 2019 at 3:09 PM Oleg Nesterov wrote: > >> On 04/16, Joel Fernandes wrote: > >> > On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote: > >> > > > >>

Re: [PATCH 2/4] clone: add CLONE_PIDFD

2019-04-15 Thread Daniel Colascione
On Mon, Apr 15, 2019 at 10:15 AM Jonathan Kowalski wrote: > > Why else do we want pidfd? > > Apart from what others have already pointed out, there are two other > things I am looking forward to: Everything that Christian, Joel, and Jonathan have said is right. If I can wax philosophical for a

Re: [PATCH RFC 1/2] Add polling support to pidfd

2019-04-12 Thread Daniel Colascione
[Resending due to accidental HTML. I need to take Joel's advice and switch to a real email client] On Fri, Apr 12, 2019 at 5:54 PM Daniel Colascione wrote: > > On Fri, Apr 12, 2019 at 5:09 PM Joel Fernandes wrote: >> >> Hi Andy! >> >> On Fri, Apr 12, 2019 at 02:

Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing

2019-04-12 Thread Daniel Colascione
On Fri, Apr 12, 2019 at 7:14 AM Daniel Colascione wrote: > > On Thu, Apr 11, 2019 at 11:53 PM Michal Hocko wrote: > > > > On Thu 11-04-19 08:33:13, Matthew Wilcox wrote: > > > On Wed, Apr 10, 2019 at 06:43:53PM -0700, Suren Baghdasaryan wrote: > > > > A

Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing

2019-04-12 Thread Daniel Colascione
On Fri, Apr 12, 2019 at 7:15 AM Suren Baghdasaryan wrote: > > On Thu, Apr 11, 2019 at 11:49 PM Michal Hocko wrote: > > > > On Thu 11-04-19 10:47:50, Daniel Colascione wrote: > > > On Thu, Apr 11, 2019 at 10:36 AM Matthew Wilcox > > > wrote: > > >

Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing

2019-04-12 Thread Daniel Colascione
On Thu, Apr 11, 2019 at 11:53 PM Michal Hocko wrote: > > On Thu 11-04-19 08:33:13, Matthew Wilcox wrote: > > On Wed, Apr 10, 2019 at 06:43:53PM -0700, Suren Baghdasaryan wrote: > > > Add new SS_EXPEDITE flag to be used when sending SIGKILL via > > > pidfd_send_signal() syscall to allow expedited

Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing

2019-04-11 Thread Daniel Colascione
On Thu, Apr 11, 2019 at 10:36 AM Matthew Wilcox wrote: > > On Thu, Apr 11, 2019 at 10:33:32AM -0700, Daniel Colascione wrote: > > On Thu, Apr 11, 2019 at 10:09 AM Suren Baghdasaryan > > wrote: > > > On Thu, Apr 11, 2019 at 8:33 AM Matthew Wilcox > > > w

Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing

2019-04-11 Thread Daniel Colascione
On Thu, Apr 11, 2019 at 10:09 AM Suren Baghdasaryan wrote: > > On Thu, Apr 11, 2019 at 8:33 AM Matthew Wilcox wrote: > > > > On Wed, Apr 10, 2019 at 06:43:53PM -0700, Suren Baghdasaryan wrote: > > > Add new SS_EXPEDITE flag to be used when sending SIGKILL via > > > pidfd_send_signal() syscall to

Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing

2019-04-11 Thread Daniel Colascione
On Thu, Apr 11, 2019 at 8:23 AM Suren Baghdasaryan wrote: > > > On Wed, Apr 10, 2019 at 06:43:53PM -0700, Suren Baghdasaryan wrote: > > > > Add new SS_EXPEDITE flag to be used when sending SIGKILL via > > > > pidfd_send_signal() syscall to allow expedited memory reclaim of the > > > > victim

Re: [RFC PATCH] fork: add CLONE_PIDFD

2019-04-10 Thread Daniel Colascione
Thanks for trying it both ways. On Wed, Apr 10, 2019 at 4:43 PM Christian Brauner wrote: > > Hey Linus, > > This is an RFC for adding a new CLONE_PIDFD flag to clone() as > previously discussed. > While implementing this Jann and I ran into additional complexity that > prompted us to send out an

Re: [RFC-2 PATCH 4/4] samples: show race-free pidfd metadata access

2019-04-10 Thread Daniel Colascione
Thanks for providing this example. A new nits below. On Wed, Apr 10, 2019 at 4:43 PM Christian Brauner wrote: > > This is an sample program to show userspace how to get race-free access to > process metadata from a pidfd. > It is really not that difficult and instead of burdening the kernel with

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-04-01 Thread Daniel Colascione
On Mon, Apr 1, 2019 at 3:13 PM Linus Torvalds wrote: > > On Mon, Apr 1, 2019 at 2:58 PM Jonathan Kowalski wrote: > > > > You mention the race about learning the PID, PID being recycled, and > > pidfd_open getting the wrong reference. > > > > This exists with the /proc model to way. How do you

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-04-01 Thread Daniel Colascione
On Mon, Apr 1, 2019 at 9:30 AM Linus Torvalds wrote: > > On Mon, Apr 1, 2019 at 9:22 AM Daniel Colascione wrote: > > > > There's a subtlety: suppose I'm a library and I want to create a > > private subprocess. I use the new clone facility, whatever it is, and >

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-04-01 Thread Daniel Colascione
On Mon, Apr 1, 2019 at 9:07 AM Jonathan Kowalski wrote: > > On Mon, Apr 1, 2019 at 4:55 PM Daniel Colascione wrote: > > > > On Mon, Apr 1, 2019 at 8:36 AM Linus Torvalds > > wrote: > > > > > > On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote: > >

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-04-01 Thread Daniel Colascione
On Mon, Apr 1, 2019 at 9:01 AM Linus Torvalds wrote: > > On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote: > > > > > > > I wonder if we really want a fill procfs2, or maybe we could just make > > > the pidfd readable (yes, it's a directory file descript

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-04-01 Thread Daniel Colascione
On Mon, Apr 1, 2019 at 8:36 AM Linus Torvalds wrote: > > On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote: > > > > Eric pitched a procfs2 which would *just* be the PIDs some time ago (in > > an attempt to make it possible one day to mount /proc inside a container > > without adding a bunch of

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-03-31 Thread Daniel Colascione
On Sun, Mar 31, 2019 at 8:05 AM Christian Brauner wrote: > > On Sun, Mar 31, 2019 at 07:52:28AM -0700, Linus Torvalds wrote: > > On Sat, Mar 30, 2019 at 9:47 PM Jann Horn wrote: > > > > > > Sure, given a pidfd_clone() syscall, as long as the parent of the > > > process is giving you a pidfd for

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-03-30 Thread Daniel Colascione
On Sat, Mar 30, 2019 at 9:24 AM Linus Torvalds wrote: > > On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner > wrote: > > > > From pure API perspective that's all I care about: independence of procfs. > > Once we have pidfd_open() we can cleanly signal threads etc. > > But "independence from

Re: [PATCH v2 0/5] pid: add pidfd_open()

2019-03-30 Thread Daniel Colascione
On Sat, Mar 30, 2019 at 9:09 AM Linus Torvalds wrote: > > On Fri, Mar 29, 2019 at 8:54 AM Christian Brauner > wrote: > > > > /* Introduction */ > > This adds the pidfd_open() syscall. > > pidfd_open() allows to retrieve file descriptors for a given pid. This > > includes both file descriptors

Re: [PATCH 2/4] pid: add pidfd_open()

2019-03-30 Thread Daniel Colascione
On Sat, Mar 30, 2019 at 7:30 AM Jonathan Kowalski wrote: > > On Sat, Mar 30, 2019 at 7:39 AM Daniel Colascione wrote: > > > > [SNIP] > > > > Thanks again. > > > > I agree that the operation we're discussing has a simple signature, > > but signa

Re: [PATCH 2/4] pid: add pidfd_open()

2019-03-30 Thread Daniel Colascione
On Fri, Mar 29, 2019 at 11:25 PM Jonathan Kowalski wrote: > > On Sat, Mar 30, 2019 at 5:35 AM Daniel Colascione wrote: > > > > On Thu, Mar 28, 2019 at 3:38 AM Christian Brauner > > wrote: > > > > > > > All that said, thanks for the work on this onc

Re: [PATCH 2/4] pid: add pidfd_open()

2019-03-29 Thread Daniel Colascione
On Thu, Mar 28, 2019 at 3:38 AM Christian Brauner wrote: > > > All that said, thanks for the work on this once again. My intention is > > just that we don't end up with an API that could have been done better > > and be cleaner to use for potential users in the coming years. > > Thanks for your

Re: [PATCH v1 2/4] pid: add pidctl()

2019-03-26 Thread Daniel Colascione
rauner wrote: > > > > On Tue, Mar 26, 2019 at 05:23:37PM +0100, Christian Brauner wrote: > > > > > On Tue, Mar 26, 2019 at 09:17:07AM -0700, Daniel Colascione wrote: > > > > > > Thanks for the patch. > > > > > > > > > > &g

Re: [PATCH v1 2/4] pid: add pidctl()

2019-03-26 Thread Daniel Colascione
On Tue, Mar 26, 2019 at 9:44 AM Christian Brauner wrote: > > On Tue, Mar 26, 2019 at 09:38:31AM -0700, Daniel Colascione wrote: > > On Tue, Mar 26, 2019 at 9:34 AM Christian Brauner > > wrote: > > > > > > On Tue, Mar 26, 2019 at 05:31:42PM +0100, Christian B

Re: [PATCH v1 2/4] pid: add pidctl()

2019-03-26 Thread Daniel Colascione
On Tue, Mar 26, 2019 at 9:34 AM Christian Brauner wrote: > > On Tue, Mar 26, 2019 at 05:31:42PM +0100, Christian Brauner wrote: > > On Tue, Mar 26, 2019 at 05:23:37PM +0100, Christian Brauner wrote: > > > On Tue, Mar 26, 2019 at 09:17:07AM -0700, Daniel Colascione

Re: [PATCH v1 2/4] pid: add pidctl()

2019-03-26 Thread Daniel Colascione
On Tue, Mar 26, 2019 at 9:23 AM Christian Brauner wrote: > > On Tue, Mar 26, 2019 at 09:17:07AM -0700, Daniel Colascione wrote: > > Thanks for the patch. > > > > On Tue, Mar 26, 2019 at 8:55 AM Christian Brauner > > wrote: > > > > > > The pi

Re: [PATCH v1 2/4] pid: add pidctl()

2019-03-26 Thread Daniel Colascione
Thanks for the patch. On Tue, Mar 26, 2019 at 8:55 AM Christian Brauner wrote: > > The pidctl() syscalls builds on, extends, and improves translate_pid() [4]. > I quote Konstantins original patchset first that has already been acked and > picked up by Eric before and whose functionality is

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 3:37 PM Jonathan Kowalski wrote: > > On Mon, Mar 25, 2019 at 10:07 PM Daniel Colascione wrote: > > > > On Mon, Mar 25, 2019 at 2:55 PM Jonathan Kowalski > > wrote: > > > > > > On Mon, Mar 25, 2019 at 9:43 PM Joel Fernandes &

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 2:55 PM Jonathan Kowalski wrote: > > On Mon, Mar 25, 2019 at 9:43 PM Joel Fernandes wrote: > > > > On Mon, Mar 25, 2019 at 10:19:26PM +0100, Jann Horn wrote: > > > On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes > > > wrote: > > > > > > But often you don't just want to

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 2:11 PM Joel Fernandes wrote: > > On Mon, Mar 25, 2019 at 09:15:45PM +0100, Christian Brauner wrote: > > On Mon, Mar 25, 2019 at 01:36:14PM -0400, Joel Fernandes wrote: > > > On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote: > &g

Re: pidfd design

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 1:14 PM Jann Horn wrote: > > On Mon, Mar 25, 2019 at 8:44 PM Andy Lutomirski wrote: > > On Wed, Mar 20, 2019 at 12:40 PM Daniel Colascione > > wrote: > > > On Wed, Mar 20, 2019 at 12:14 PM Christian Brauner > > > wrote: > > &g

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 12:42 PM Jonathan Kowalski wrote: > > On Mon, Mar 25, 2019 at 6:57 PM Daniel Colascione wrote: > > > > On Mon, Mar 25, 2019 at 11:19 AM Jonathan Kowalski > > wrote: > > > > > > On Mon, Mar 25, 2019 at 5:53 PM Daniel Colasci

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 11:19 AM Jonathan Kowalski wrote: > > On Mon, Mar 25, 2019 at 5:53 PM Daniel Colascione wrote: > > > > [..snip..] > > > > I don't like the idea of having one kind of pollfd be pollable and > > another not. Such an interface would be

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 10:36 AM Joel Fernandes wrote: > > On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote: > > On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner > > wrote: > > > The pidctl() syscalls builds on, extends, and improves translate_pid(

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 10:05 AM Konstantin Khlebnikov wrote: > On 25.03.2019 19:48, Daniel Colascione wrote: > > On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner > > wrote: > >> The pidctl() syscalls builds on, extends, and improves translate_pid() [4]. > >

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 9:56 AM David Howells wrote: > Daniel Colascione wrote: > > > System calls are cheap. > > Only to a point. x86_64 will have an issue when we hit syscall 512. We're > currently at 427. IIRC, a while ago, someone proposed restarting system call n

Re: [PATCH 0/4] pid: add pidctl()

2019-03-25 Thread Daniel Colascione
On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner wrote: > The pidctl() syscalls builds on, extends, and improves translate_pid() [4]. > I quote Konstantins original patchset first that has already been acked and > picked up by Eric before and whose functionality is preserved in this > syscall.

  1   2   3   4   >