]> git-server-git.apps.pok.os.sepia.ceph.com Git - xfsprogs-dev.git/commit
libxfs: fix atomic64_t poorly for 32-bit architectures xfsprogs-5.14-fixes_2021-11-23
authorDarrick J. Wong <djwong@kernel.org>
Tue, 23 Nov 2021 00:09:31 +0000 (16:09 -0800)
committerDarrick J. Wong <djwong@kernel.org>
Tue, 23 Nov 2021 19:50:30 +0000 (11:50 -0800)
commitddb05b911eeac00611028fdcffdadfd208480122
treee0fd06c0422b1fda224a0928e9c4869cd57d10e7
parent5b967e173b29ac18f1eb04a6339199f51114dcfd
libxfs: fix atomic64_t poorly for 32-bit architectures

In commit de555f66, we converted the atomic64_t implementation to use
the liburcu uatomic_* functions.  Regrettably, nobody tried to build
xfsprogs on a 32-bit architecture (hint: maintainers don't scale well
anymore) so nobody noticed that the build fails due to the unknown
symbol _uatomic_link_error.  This is what happens when liburcu doesn't
know how to perform atomic updates to a variable of a certain size, due
to some horrid macro magic in urcu.h.

Rather than a strict revert to non-atomic updates for these platforms or
(which would introduce a landmine) or roll everything back for the sake
of older platforms, I went with providing a custom atomic64_t
implementation that uses a single pthread mutex.  This enables us to
work around the fact that the kernel atomic64_t API doesn't require a
special initializer function, and is probably good enough since there
are only a handful of atomic64_t counters in the kernel.

Clean up the type declarations of a couple of variables in libxlog to
match the kernel usage, though that's probably overkill.

Eventually we'll want to decide if we're deprecating 32-bit, but this
fixes them in the mean time.

Fixes: de555f66 ("atomic: convert to uatomic")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
configure.ac
include/atomic.h
include/builddefs.in
include/libxlog.h
libxfs/init.c
m4/package_urcu.m4
repair/phase2.c