On 17 January 2016 at 02:05, Ahmed S. Darwish <darwish.07 at gmail.com> wrote: > 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 :) Yeeesh, nice catch. :-) -- Arun
