linux-kernel - Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

lists.openwall.net		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 linux-hardening linux-cve-announce 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:   Sat, 16 Mar 2019 10:31:45 -0700
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Christian Brauner <christian@...uner.io>,
        Daniel Colascione <dancol@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sultan Alsawaf <sultan@...neltoast.com>,
        Tim Murray <timmurray@...gle.com>,
        Michal Hocko <mhocko@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        Todd Kjos <tkjos@...roid.com>,
        Martijn Coenen <maco@...roid.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
        linux-mm <linux-mm@...ck.org>,
        kernel-team <kernel-team@...roid.com>
Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes <joel@...lfernandes.org> 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
> > > 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: http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html
>
> May be a dedicated syscall for this would be cleaner after all.

Ah, I wish I've seen that discussion before...
syscall makes sense and it can be non-blocking and we can use
select/poll/epoll if we use eventfd. I would strongly advocate for
non-blocking version or at least to have a non-blocking option.
Something like this:

evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
// register eventfd to receive death notification
pidfd_wait(pid_to_kill, evfd);
// kill the process
pidfd_send_signal(pid_to_kill, ...)
// tend to other things
...
// wait for the process to die
poll_wait(evfd, ...);

This simplifies userspace, allows it to wait for multiple events using
epoll and I think kernel implementation will be also quite simple
because it already implements eventfd_signal() that takes care of
waitqueue handling.

If pidfd_send_signal could be extended to have an optional eventfd
parameter then we would not even have to add a new syscall.

> > 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 :)).
>
> thanks,
>
>  - Joel
>