Session suspension and restoration protocol

[Simon McVittie]

On Tue, 19 Jun 2018 at 16:21:14 +0200, Michel Dänzer wrote:
> On 2018-06-19 02:22 PM, Simon McVittie wrote:
> > This indirect launching also avoids doing a fork-and-exec in the
> > compositor or session manager, which can be problematic under low-memory
> > conditions: the kernel needs to allocate enough virtual memory space for
> > a second copy of the parent process (even though the physical memory that
> > backs it is going to be copy-on-write, and in fork-and-exec it only exists
> > briefly and is mostly unmodified)
> 
> FWIW, /dev/dri/* files are supposed to be always opened with O_CLOEXEC,
> to prevent the file descriptors from leaking to children.

Sure, but that's close-on-exec, not close-on-fork. The kernel doesn't
know you aren't going to continue executing application-level code in
both parent and child[1].

> There were
> bugs in libdrm meaning this didn't always happen, but those are fixed in
> current upstream.

Just about everything is *meant to be* opened O_CLOEXEC, but that doesn't
mean it is :-)

    smcv

[1] Never do this if your process might be multi-threaded, and probably
    don't do this even if it's known to be single-threaded