[pulseaudio-discuss] [PATCH DEBUG] pulse: Enable memfd for client palyback

[Arun Raghavan]

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