[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