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

Arun Raghavan arun at accosted.net
Sun Jan 17 20:49:39 PST 2016

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

More information about the pulseaudio-discuss mailing list