On Mon, Sep 21, 2015 at 03:20:01AM +0200, Ahmed S. Darwish wrote: > Hi, > > This is a debugging patch I'm sending to ask for help for a bug > I'm currently facing when enabling memfd for client playback audio. > > In this patch, I simply transform the client playback mempool > (context->mempool) to be backed by memfd shared memory instead of > posix SHM one. > [...] > when doing so for the playback mempool, sometimes pstreams code > reach do_read() with a flag PA_FLAG_MEMFD_FD (implying that this is > indeed a marshalled memfd-block frame), but with a reset ancillary > data field (nfd = 0) and no memfd descriptors > woooooooooot, bug cause discovered. This was an fd leak that, in interaction with UNIX sockets fd passing, manifested itself in a very weird manner! ## Situation: - Over time, PA daemon reaches its open fd limit (due to fd leak) - a client sends a memfd fd, as ancil data, over the socket ## Expected result: - Kernel fails at the recvmsg() system call, complaining with something like -EMFILE ## What actually happens: - Kernel won't complain at all, or even return any kind of error. It will just _silently_ strip the file descriptor from the passed ancil message. - Naturally, this leads to broken expectations from the pstream side. (pstream code expecting a passed file descriptor but finds nothing) - /me wondering how the passed fd could silently vanish in this manner (originally blamed on a misunderstanding of pstreams behavior) Anyway, this was a blocker for this patch series that is now fixed :) Regards, -- Darwish http://darwish.chasingpointers.com
