| Summary: | memfd doesn't work between 64-bit server and 32-bit client | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Tanu Kaskinen <tanuk> |
| Component: | clients | Assignee: | Ahmed S. Darwish <darwish.07> |
| Status: | RESOLVED FIXED | QA Contact: | pulseaudio-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | darwish.07, lennart, userwithuid |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 96750 | ||
Marking as a 10.0 blocker. Just a quick follow up on this (I was the one who mentioned this on irc). Original report was using arch, but i can confirm the issue is also present with ubuntu 16.10beta packages on a liveusb i had at hand. Logs for server and client show nothing new. So looks like a proper bug. Interesting; will install a 32-bit userland and trace up things. This seems to be a bug in pulse iochannel layer + a subtle bug in the kernel's 32-bit socket emulation layer. Please check the fix I've just posted below, which fixes the issue on my side:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-November/027159.html
Thanks a lot for submitting this critical bug report :-)
Works for me using custom PA 9.0 arch pkgs with your patch applied, thanks for the fix. If I understand correctly, the current solution requires the fix to be applied in the 32-bit client libs (libpulsecommon)? If that's true, this could be a small problem for the 10.0 memfd default: Default 9.0 seems to compile memfd and use it client-side (unless explicitly disabled in client.conf) when the server requests it (which the 10.0 server will do by default). Ideally, this shouldn't be a problem as the client can be updated to 10.0 like the server, but bundling/snapshotting/embedding libs obviously happens in practice (e.g. steam, games). As of right now, this is mostly a theoretical issue because the legacy 32-bit clients I'm aware of use <9.0 anyway and therefore don't have memfd at all. But until a fixed 9.1 or 10.0 is released, faulty 9.0 clients have time to get adopted in such bundles. That is, if I got this right, it's a little confusing and I might have missed something. :-) Glad that the patch works ;-) Regarding the possibility of this bug biting people in the future if they bundle 9.0 libraries and work against a 10.0/11.0/+ server, that's a very good point. Instead of releasing a 9.1 though (which might or might not be bundled after all), I'm thinking of adding special code to 10.0 server side: refuse declaring server's memfd support if the client version is < 10.0. Tanu, what do you think about this? Thanks a lot for the patch! I applied it now: https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=451d1d676237c81c4d7e64b2480d2010b48d3348 (In reply to Ahmed S. Darwish from comment #6) > Instead of releasing a 9.1 though (which might or might not be bundled after > all), I'm thinking of adding special code to 10.0 server side: refuse > declaring server's memfd support if the client version is < 10.0. > > Tanu, what do you think about this? Adding a version check would probably be trivial. Would you be willing to make a patch? On Thu, Nov 17, 2016 at 05:48:25PM +0000, bugzilla-daemon@freedesktop.org wrote: > > --- Comment #8 from Tanu Kaskinen <tanuk@iki.fi> --- > (In reply to Ahmed S. Darwish from comment #6) > > Instead of releasing a 9.1 though (which might or might not be bundled after > > all), I'm thinking of adding special code to 10.0 server side: refuse > > declaring server's memfd support if the client version is < 10.0. > > > > Tanu, what do you think about this? > > Adding a version check would probably be trivial. Would you be willing to make > a patch? > Yeah, expect the patch by tomorrow. It would be important to include that before a 10.0 release. Server modified not to signal memfd support for the buggy 9.0 clients. Patch here:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-November/027166.html
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
It was reported in IRC that while memfd works with 64-bit clients, 32-bit clients get disconnected during the connection setup phase. Disabling memfd makes things work. The last log messages at the client side are: Negotiated SHM type: shared memfd Connection failure: Connection terminated The last log messages at the server side are: D: [pulseaudio] protocol-native.c: Enabling srbchannel... I: [pulseaudio] client.c: Freed 1 "Native client (UNIX socket client)" I: [pulseaudio] protocol-native.c: Connection died. So neither party complains about a protocol error, the connection seems to somehow die spontaneously.