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

Ahmed S. Darwish darwish.07 at gmail.com
Sat Jan 16 12:35:03 PST 2016


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


More information about the pulseaudio-discuss mailing list