From: Imre Kaloz <kaloz@kernel.org>
To: Andreas Larsson <andreas@gaisler.com>, sparclinux@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org, Magnus Lindholm <linmag7@gmail.com>
Subject: [PATCH 0/3] sparc32: SMP futexes, casa and idiv emulation
Date: Sun, 27 Sep 2026 02:58:18 +0200 [thread overview]
Message-ID: <20260927005821.8369-1-kaloz@kernel.org> (raw)
sun4m has no compare-and-swap instruction and casa is optional on
LEON, so SMP sparc32 has had no futexes, and user code on those CPUs
has no CAS to build locks from.
Patch 1 implements the futex atomic ops in atomic32.c and drops the
!(SPARC32 && SMP) dependency of FUTEX. A LEON part that implements
casa, found by a boot-time probe, runs casa on the user word; other
CPUs take the __atomic_hash spinlocks.
Patch 2 completes user casa from illegal_instruction on CPUs without
it, through patch 1's futex_atomic_cmpxchg_inatomic(), so emulated
casa and the futex ops serialize on the same lock. It is atomic
against itself and against the futex ops, not against a plain store
to the same word, so a C library using it has to do its atomic stores
with casa too.
Patch 3 completes udiv, sdiv and their -cc forms from the same
do_illegal_instruction() dispatch: SuperSPARC and SuperSPARC-II trap
those when the {Y, rs1} dividend has significant bits above bit 51,
which gcc -mcpu=v8 output, including libgcc's __udivdi3, can produce.
It shares patch 2's windowed-operand helpers and the dispatch block,
which is why it comes last.
Patch 1 comes first because patch 2 is built on it. On its own it
races nothing: without patch 2, user casa on these CPUs is SIGILL.
Magnus Lindholm has an independent RFC covering the same ground from
a different ABI: "[RFC PATCH 0/5] sparc32: kernel assisted
compare-and-swap, and futex on SMP" (patchwork sparclinux, Message-Id
20260923201830.865553-1-linmag7@gmail.com), with a companion glibc
series (patchwork glibc, Message-Id
20260924064228.867909-1-linmag7@gmail.com). That RFC adds a new
software trap, ta 0x11 (trap type 0x91), extending David Miller's
2016 CAS-trap prototype at ta 0x23 rather than completing it, so
userspace has to be rebuilt to call it. This series instead
completes the casa opcode itself, so a binary already emitting casa
(gcc -mcpu=leon3 or -mcpu=v9 output, or a C library that encodes it
as a .word) runs unmodified on a CPU without hardware casa, with no
new trap number and no libc rebuild. Happy to share the futex and
do_illegal_instruction() plumbing with whichever ABI lands.
Andreas: do LEON3FT parts want the GRLIB-TN-0010/0011 "nop; .balignl
16" alignment before the casa word here, or is the plain encoding as
posted fine for them?
Notes, not for the log:
- checkpatch on patch 1: "Lines should not end with a '('" is the
__asm__ __volatile__( idiom of uaccess_32.h; the -ENOSYS warning is
the futex API's return for an unknown op, as on every architecture.
"does MAINTAINERS need updating?" on patches 2 and 3 is covered by
the F: arch/sparc/ entry.
- On qemu's SS-20 with two SuperSPARCs and the casa emulation alone,
futex() returns ENOSYS and musl's mutex, PI mutex and robust mutex
tests fail. With patches 1 and 2 they pass, as does a PI lock
contended between user casa and FUTEX_LOCK_PI/FUTEX_UNLOCK_PI on
both CPUs.
- The casa branch of the futex ops has not run on LEON hardware. The
probe runs on LEON only; its fixup path, which a LEON without casa
takes, has run only in a test kernel that forced the probe on
qemu's SS-20.
- The divide emulation has run on no CPU that traps it. No sparc32
model in qemu raises the trap, and no SuperSPARC or SuperSPARC-II
was available for this series; it is exercised only by build and
link.
Imre Kaloz (3):
sparc32: support futexes on SMP
sparc32: emulate casa on V8 CPUs
sparc32: emulate integer divide taken as illegal_instruction
arch/sparc/include/asm/futex_32.h | 6 +-
arch/sparc/kernel/Makefile | 2 +
arch/sparc/kernel/cas_emu_32.c | 117 +++++++++++++++++++++++++++
arch/sparc/kernel/div_emu_32.c | 127 ++++++++++++++++++++++++++++++
arch/sparc/kernel/entry.h | 2 +
arch/sparc/kernel/traps_32.c | 23 +++++-
arch/sparc/kernel/unimp_32.h | 71 +++++++++++++++++
arch/sparc/lib/atomic32.c | 122 ++++++++++++++++++++++++++++
init/Kconfig | 1 -
9 files changed, 468 insertions(+), 3 deletions(-)
create mode 100644 arch/sparc/kernel/cas_emu_32.c
create mode 100644 arch/sparc/kernel/div_emu_32.c
create mode 100644 arch/sparc/kernel/unimp_32.h
base-commit: 62f4c998b297cf233997a2b4cd6fc2d2df0319c9
--
2.47.3
next reply other threads:[~2026-09-27 0:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 0:58 Imre Kaloz [this message]
2026-09-27 0:58 ` [PATCH 1/3] sparc32: support futexes on SMP Imre Kaloz
2026-10-04 8:51 ` Magnus Lindholm
2026-09-27 0:58 ` [PATCH 2/3] sparc32: emulate casa on V8 CPUs Imre Kaloz
2026-10-04 9:02 ` Magnus Lindholm
2026-10-15 14:15 ` Ramin Moussavi
2026-10-15 14:32 ` Magnus Lindholm
2026-10-15 19:08 ` Imre Kaloz
2026-10-15 20:01 ` Ramin Moussavi
2026-09-27 0:58 ` [PATCH 3/3] sparc32: emulate integer divide taken as illegal_instruction Imre Kaloz
2026-09-27 21:25 ` Magnus Lindholm
2026-10-04 9:05 ` Magnus Lindholm
2026-09-27 21:42 ` [PATCH 0/3] sparc32: SMP futexes, casa and idiv emulation Magnus Lindholm
2026-10-04 10:04 ` Magnus Lindholm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260927005821.8369-1-kaloz@kernel.org \
--to=kaloz@kernel.org \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=linmag7@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.