]> git.apps.os.sepia.ceph.com Git - xfsprogs-dev.git/commit
libxfs: fix atomic64_t detection on x86 32-bit architectures
authorDarrick J. Wong <djwong@kernel.org>
Tue, 12 Sep 2023 19:47:51 +0000 (12:47 -0700)
committerCarlos Maiolino <cem@kernel.org>
Thu, 5 Oct 2023 12:57:20 +0000 (14:57 +0200)
commit21226bb466c1053c0f9b2e600bbbee2f7a6960a2
tree98f14c49fe95b981886a2e517805d5425c35dcf8
parent75325b82a66185ae9d0360193a271640e8c9a3ea
libxfs: fix atomic64_t detection on x86 32-bit architectures

xfsprogs during compilation tries to detect if liburcu supports atomic
64-bit ops on the platform it is being compiled on, and if not it falls
back to using pthread mutex locks.

The detection logic for that fallback relies on _uatomic_link_error()
which is a link-time trick used by liburcu that will cause compilation
errors on archs that lack the required support. That only works for the
generic liburcu code though, and it is not implemented for the
x86-specific code.

In practice this means that when xfsprogs is compiled on 32-bit x86
archs will successfully link to liburcu for atomic ops, but liburcu does
not support atomic64_t on those archs. It indicates this during runtime
by generating an illegal instruction that aborts execution, and thus
causes various xfsprogs utils to be segfaulting.

Fix this by requiring that unsigned longs are at least 64 bits in size,
which /usually/ means that 64-bit atomic counters are supported.  We
can't simply execute the liburcu atomic64_t detection code during
configure instead of only relying on the linker error because that
doesn't work for cross-compiled packages.

Fixes: 7448af588a2e ("libxfs: fix atomic64_t poorly for 32-bit architectures")
Reported-by: Anthony Iliopoulos <ailiop@suse.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
m4/package_urcu.m4