lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Mar 2019 14:49:03 -0400
From:   Joel Fernandes <>
To:     Christian Brauner <>
Cc:     Daniel Colascione <>,
        Steven Rostedt <>,
        Sultan Alsawaf <>,
        Tim Murray <>,
        Michal Hocko <>,
        Suren Baghdasaryan <>,
        Greg Kroah-Hartman <>,
        Arve Hjønnevåg <>,
        Todd Kjos <>,
        Martijn Coenen <>,
        Ingo Molnar <>,
        Peter Zijlstra <>,
        LKML <>,
        "open list:ANDROID DRIVERS" <>,
        linux-mm <>,
        kernel-team <>
Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

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
> > standard poll/epoll interface on the proc fd like Daniel was suggesting.
> > AFAIK, once the proc file is opened, the struct pid is essentially pinned
> > even though the proc number may be reused. Then the caller can just poll.
> > We can add a waitqueue to struct pid, and wake up any waiters on process
> > death (A quick look shows task_struct can be mapped to its struct pid) and
> > also possibly optimize it using Steve's TIF flag idea. No new syscall is
> > needed then, let me know if I missed something?
> Huh, I thought that Daniel was against the poll/epoll solution?

Hmm, going through earlier threads, I believe so now. Here was Daniel's
reasoning about avoiding a notification about process death through proc
directory fd:

May be a dedicated syscall for this would be cleaner after all.

> I have no clear opinion on what is better at the moment since I have
> been mostly concerned with getting pidfd_send_signal() into shape and
> was reluctant to put more ideas/work into this if it gets shutdown.
> Once we have pidfd_send_signal() the wait discussion makes sense.

Ok. It looks like that is almost in though (fingers crossed :)).


 - Joel

Powered by blists - more mailing lists