[pulseaudio-tickets] [Bug 94629] PulseAudio gets reliably killed upon a big number of client connections

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94629

--- Comment #2 from Ahmed S. Darwish <darwish.07 at gmail.com> ---
Hi Alex,

On Sun, Mar 20, 2016 at 05:48:28AM +0000, bugzilla-daemon at freedesktop.org
wrote:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=94629
> 
> --- Comment #1 from Alexander E. Patrakov <patrakov at gmail.com> ---
> Thanks for the report. The kills may happen because of exceeding the allowed
> real-time budget. To verify this, please modify /etc/pulse/daemon.conf:
>
> realtime-scheduling=no
>

Thanks! This indeed confirms that PA reliably exceeds its RT budget.
Adding `realtime-scheduling=no' makes the bug completely vanish.
Reset the option back to yes, and PA gets reliably killed again.

After applying Arun's kernel rlimits verbosity patch, here is what
I see in dmesg when PA gets unsolicitedly killed:

  [23891.784010] CPU Watchdog Timeout (hard): alsa-sink-VT170[7131]

So this also adds another confirmation and shows why the bug does
not appear by using NULL sinks..

[ Hmm, .. thinking about solutions ]

Unfortunately lowering the maximum amount of clients is not a
solution: on Tanu's machine, sometimes even just 18 clients did
the trick :-(

One of the reasons of the memfd + making pools per-client patches
is to make PA a little bit safer as a system daemon (a fuzzer may
also be built down the road). If clients can trigger a reliable
PulseAudio kill, we have a reliable DoS attack on our hands..

So now the question is, how to modify PA to make sure it does not
exceed its RT budget?


Regards,
Darwish

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20160320/3e49c372/attachment-0001.html>