libxfs: fix atomic64_t poorly for 32-bit architectures

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.

[sandeen: make the custom atomic64_add() take an int64_t]

Fixes: de555f66 ("atomic: convert to uatomic")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>