linux-kernel - Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

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] [day] [month] [year] [list]

Date:   Thu, 02 Nov 2017 08:24:50 -0700
From:   Shawn Paul Landden <slandden@...il.com>
To:     Colin Walters <walters@...bum.org>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes
 process to death row (new syscall)

On Wed, 2017-11-01 at 15:37 -0400, Colin Walters wrote:
> threading is limited doing sync()/fsync() and gethostbyname() async.
> 
> But languages with a GC tend to at least use a background thread for
> that,
> and of course lots of modern userspace makes heavy use of
> multithreading
> (or variants like goroutines).
> 
> A common pattern though is to have a "main thread" that acts as a
> control
> point and runs the mainloop (particularly for anything with a GUI).  
> That's
> going to be the thing calling prctl(SET_IDLE) - but I think its idle
> state should implicitly
> affect the whole process, since for a lot of apps those other threads
> are going to
> just be "background".
> 
> It'd probably then be an error to use prctl(SET_IDLE) in more than
> one thread
> ever?  (Although that might break in golang due to the way goroutines
> can
> be migrated across threads)
> 
> That'd probably be a good "generality test" - what would it take to
> have
> this system call be used for a simple golang webserver app that's
> e.g.
> socket activated by systemd, or a Kubernetes service?  Or another
> really interesting case would be qemu; make it easy to flag VMs as
> always
> having this state (most of my testing VMs are like this; it's OK if
> they get
> destroyed, I just reinitialize them from the gold state).
> 
> Going back to threading - a tricky thing we should handle in general
> is when userspace libraries create threads that are unknown to the
> app;
> the "async gethostbyname()" is a good example.  To be conservative
> we'd
> likely need to "fail non-idle", but figure out some way tell the
> kernel
> for e.g. GC threads that they're still 
I realize none of this is a problem because when prctl(PR_SET_IDLE,
PR_IDLE_MODE_KILLME) is set the *entire* process has declared itsself
stateless and ready to be killed.