Skip to content

multiprocess program gets incorrect results with qemu arm-linux-user

This bug has been copied automatically from: https://bugs.launchpad.net/qemu/+bug/1585840

The attached program can run either in a threaded mode or a multiprocess
mode.  It defaults to threaded mode, and switches to multiprocess mode if
the first positional argument is "process".  "success" of the test is
defined as the final count being seen as 2000000 by both tasks.

In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf
userspace (4 cores), the test program consistently completes successfully
in both modes.  But with qemu arm-linux-user, the test consistently
succeeds in threaded mode and generally fails in multiprocess mode.

The test reflects an essential aspect of how the Free and Open Source
project linuxcnc's IPC system works: shared memory regions (created by
shmat, but mmap would probably behave the same) contain data and mutexes.
I observed that our testsuite encounters numerous deadlocks and failures
when running in an schroot with qemu-user (x86_64 host), and I believe the
underlying cause is improper support for atomic operations in a
multiprocess model. (the testsuite consistently passes on real hardware)

I observed the same failure at v1.6.0 and master (v2.6.0-424-g287db79), as
well as in the outdated Debian version 1:2.1+dfsg-12+deb8u5a.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information