On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
>
> On Thu, 14 Mar 2019 13:49:11 -0700
> Sultan Alsawaf wrote:
>
> > Perhaps I'm missing something, but if you want to know when a process has
> > died
> > after sending a SIGKILL to it, then why not just make the SIGKILL optionally
> > block
On Fri, Mar 15, 2019 at 8:56 AM Suren Baghdasaryan wrote:
>
> On Thu, Mar 14, 2019 at 9:37 PM Daniel Colascione wrote:
> >
> > On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> > >
> > > On Thu, 14 Mar 2019 13:49:11 -0700
> > > Sultan Alsa
On Fri, Mar 15, 2019 at 9:43 AM Steven Rostedt wrote:
>
> On Thu, 14 Mar 2019 21:36:43 -0700
> Daniel Colascione wrote:
>
> > On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> > >
> > > On Thu, 14 Mar 2019 13:49:11 -0700
> > > Sultan Alsa
On Fri, Jan 25, 2019 at 11:01 AM wrote:
>
> On January 24, 2019 12:59:29 PM PST, Joel Fernandes
> wrote:
> >On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote:
> >>
> >> On 1/23/19 11:37 PM, Daniel Colascione wrote:
> >[..]
> >> >
On Fri, Jan 25, 2019 at 12:28 PM wrote:
>
> On January 25, 2019 11:15:52 AM PST, Daniel Colascione
> wrote:
> >On Fri, Jan 25, 2019 at 11:01 AM wrote:
> >>
> >> On January 24, 2019 12:59:29 PM PST, Joel Fernandes
> > wrote:
> >> >On Thu, Jan
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 preser
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
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 wrote:
&
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
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
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 pro
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
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
On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan wrote:
>
> On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes
> wrote:
> >
> > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote:
> > [..]
> > > > why do we want to add a new syscall (pidfd_wait) though? Why not just
> > > > use
>
e:
> > > >
> > > > On Sat, Mar 16, 2019 at 11:00:10AM -0700, Daniel Colascione wrote:
> > > > > On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Mar 15, 2
t; > > On Sat, Mar 16, 2019 at 11:57 AM Christian Brauner
> > > > wrote:
> > > > >
> > > > > On Sat, Mar 16, 2019 at 11:00:10AM -0700, Daniel Colascione wrote:
> > > > > > On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan
&g
On Tue, Mar 19, 2019 at 3:14 PM Christian Brauner wrote:
> So I dislike the idea of allocating new inodes from the procfs super
> block. I would like to avoid pinning the whole pidfd concept exclusively
> to proc. The idea is that the pidfd API will be useable through procfs
> via open("/proc/") b
On Tue, Mar 19, 2019 at 6:52 PM Joel Fernandes wrote:
>
> On Wed, Mar 20, 2019 at 12:10:23AM +0100, Christian Brauner wrote:
> > On Tue, Mar 19, 2019 at 03:48:32PM -0700, Daniel Colascione wrote:
> > > On Tue, Mar 19, 2019 at 3:14 PM Christian Brauner
> > > wrote:
On Tue, Mar 19, 2019 at 8:59 PM Christian Brauner wrote:
>
> On Tue, Mar 19, 2019 at 07:42:52PM -0700, Daniel Colascione wrote:
> > On Tue, Mar 19, 2019 at 6:52 PM Joel Fernandes
> > wrote:
> > >
> > > On Wed, Mar 20, 2019 at 12:10:23AM +0100, Christian B
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 tre
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)
> >
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 Colascione w
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.
>
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
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 11:38
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 ]
> > > >
> >
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,
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 minim
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:
> > >
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
> &
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
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
> ---
>
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
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
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 == E
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 The
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
>
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?
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
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
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 inser
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
meral 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-acce
ndows 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
---
-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
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
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
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
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 defi
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
On Sat, Jan 19, 2019 at 11:27 AM Joel Fernandes wrote:
>
> On Sat, Jan 19, 2019 at 09:25:32AM +0100, Greg KH wrote:
> > On Fri, Jan 18, 2019 at 05:55:43PM -0500, Joel Fernandes wrote:
> > > --- /dev/null
> > > +++ b/kernel/kheaders.c
Thanks a ton for this work. It'll make it much easier to do coo
On Wed, Jan 23, 2019 at 1:29 PM Karim Yaghmour
wrote:
> > By the way, we can easily write a script to just extract the .ko directly -
> > if the whole "load it as a module" thing bothers you. The kheaders.ko can
> > just be thought of as a tarball. There's already a script to extract
> > /proc/con
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
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
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.
Sp
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
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
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 in
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
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 si
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 fo
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 proc
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 i
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 ma
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 des
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:
> >
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
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 proc_tgid_base_poll(struct
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 7:23:
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
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
>
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
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
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
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
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
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 yo
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
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 retriev
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
>
On Wed, Mar 20, 2019 at 11:26 AM Christian Brauner wrote:
> On Wed, Mar 20, 2019 at 07:33:51AM -0400, Joel Fernandes wrote:
> >
> >
> > On March 20, 2019 3:02:32 AM EDT, Daniel Colascione
> > wrote:
> > >On Tue, Mar 19, 2019 at 8:59 PM Christian Brauner
>
On Wed, Mar 20, 2019 at 11:52 AM Christian Brauner wrote:
>
> On Wed, Mar 20, 2019 at 11:38:35AM -0700, Daniel Colascione wrote:
> > On Wed, Mar 20, 2019 at 11:26 AM Christian Brauner
> > wrote:
> > > On Wed, Mar 20, 2019 at 07:33:51AM -0400, Joel Fernandes wrote:
On Wed, Mar 20, 2019 at 12:14 PM Christian Brauner wrote:
>
> On Wed, Mar 20, 2019 at 11:58:57AM -0700, Andy Lutomirski wrote:
> > On Wed, Mar 20, 2019 at 11:52 AM Christian Brauner
> > wrote:
> > >
> > > You're misunderstanding. Again, I said in my previous mails it should
> > > accept pidfds o
On Wed, Mar 20, 2019 at 1:07 PM Alexey Dobriyan wrote:
> > What would be your opinion to having a
> > /proc//handle
> > file instead of having a dirfd.
>
> This is even worse than depending on PROC_FS. Just for the dependency
> pidfd code should be backed out immediately. Forget about /proc.
We a
On Wed, Mar 20, 2019 at 1:47 PM Christian Brauner wrote:
>
> On Wed, Mar 20, 2019 at 11:39:10PM +0300, Alexey Dobriyan wrote:
> > On Wed, Mar 20, 2019 at 01:14:01PM -0700, Daniel Colascione wrote:
> > > On Wed, Mar 20, 2019 at 1:07 PM Alexey Dobriyan
> > > wrote
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. Mu
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 c
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].
> >
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(
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 wou
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
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
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:
> >
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 w
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
&
On Wed, Mar 6, 2019 at 3:09 PM Pavel Machek wrote:
>
>
> > > >Ok, I'll look into LZMA. Thanks for checking the compression sizes.
> > > >
> > > >- Joel
> > >
> > > Don't use lzma, use xz if you are going to do something.
> >
> > Ok, sounds good.
XZ is a file format for LZMA2. Everyone's right. :-
On Wed, Mar 6, 2019 at 4:07 PM H. Peter Anvin wrote:
>
> On 3/6/19 3:37 PM, Daniel Colascione wrote:
> >
> > I just don't get the opposition to Joel's work. The rest of the thread
> > already goes into detail about the problems with pure-filesystem
> >
On Wed, Mar 6, 2019 at 4:33 PM H. Peter Anvin wrote:
>
> On 3/6/19 3:37 PM, Daniel Colascione wrote:
> >
> > I just don't get the opposition to Joel's work. The rest of the thread
> > already goes into detail about the problems with pure-filesystem
> >
On Wed, Mar 6, 2019 at 5:23 PM Enrico Weigelt, metux IT consult
wrote:
>
> On 07.03.19 01:33, Daniel Colascione wrote:
>
> > *There* *may* *be* *no* *filesystem*.
>
> A Linux system w/o any filesystem at all ? Well, that's interesting.
Entirely FS-less operation is unco
On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers <
mathieu.desnoy...@efficios.com> wrote:
> By the way, if we eventually find a way to enhance user-space mutexes in
the
> fashion you describe here, it would belong to another TLS area, and would
> be registered by another system call than rseq. I pr
101 - 200 of 228 matches
Mail list logo
