A patch series proposed for Linux 7.4 would let CPUs without a dedicated instruction use 2-byte compare-and-exchange, an operation that compares a value and rewrites it only if it matches. Bradley Morgan wrote the five patches, and Paul E. McKenney bundled them into a pull request. The series targets four architectures: SH, ARC, C-SKY and Xtensa. It absorbs the differences between CPUs so that the kernel's generic code can use 2-byte compare-and-exchange. However, it does not remove the limitation that these systems have no instruction for writing 2 bytes directly. On October 20, McKenney also clarified a related discussion about ending support: it concerns a specific legacy system, the Acorn Risc PC, not the Arm architecture as a whole.
Using 4-byte compare-and-exchange to update 2 bytes
The patches add a function called cmpxchg_emu_u16(). Like the existing 1-byte emulation, it uses a 4-byte compare-and-exchange to support operations on smaller data widths. According to the patch description, the four target architectures do not support 2-byte compare-and-exchange, and using the operation could cause compile-time or link-time errors. The change fills that gap with a shared function.
Compare-and-exchange checks a value in memory against an expected value and writes a new value only if they match. Because the comparison and update happen as a single operation, it prevents overwriting a change made by another process between reading the value and writing it back. The new function performs the compare-and-exchange on the entire 4-byte region that contains the 2 bytes being updated.
In the implementation posted on October 7, the function first reads the 4-byte value with READ_ONCE() and checks whether the target 2 bytes match the expected value. If they do not, it returns the value it actually read and exits. If they match, it builds a 4-byte value that replaces only the target portion with the new value while preserving the other 2 bytes. It then attempts a compare-and-exchange against the original 4-byte value.
The adjacent 2 bytes matter in this scheme. If another process changes the neighboring portion first, the 4-byte compare-and-exchange fails even if the target 2 bytes are unchanged. The function retries using the value returned by the failed compare-and-exchange, which prevents it from writing stale neighboring data back. The implementation also includes a check that warns if the target address is not aligned to a 2-byte boundary.
The function's arguments and return value use unsigned long, but comparisons and assignments convert values to u16, so the data actually operated on remains 16 bits. According to the patch description, this design avoids type-conversion warnings that occur when architecture macros check per-size handling for compare-and-exchange on pointers. In other words, the types of the function's arguments and return value are distinct from the width of the data actually compared and updated.
Direct-write limitations remain even with compare-and-exchange support
In the pull request, McKenney explains that making 2-byte compare-and-exchange available to generic code does not make every algorithm that needs 2-byte atomic operations feasible. Some systems Linux supports have no instruction for writing a 2-byte value directly. Compare-and-exchange and a plain store of a value to memory require different hardware capabilities. Even if a 4-byte compare-and-exchange can reproduce a 2-byte one, that does not add a direct 2-byte store instruction. An algorithm that depends on both operations therefore cannot assume its requirements are met by compare-and-exchange support alone.
To understand this change, it is necessary to distinguish between 2-byte compare-and-exchange, 2-byte direct writes, and the removal of support for a legacy system. They differ not only in technical requirements but also in their place in development. Combining McKenney's pull request with his October 20 clarification gives the following picture:
| Item | Scope and technical conditions | Status as of October 20, 2026 |
|---|---|---|
| 2-byte compare-and-exchange | Implemented on SH, ARC, C-SKY and Xtensa using 4-byte compare-and-exchange | Pull requested for Linux 7.4 |
| 2-byte direct writes | No instruction exists on some supported systems | Limitation remains after compare-and-exchange emulation |
| Removal of Acorn Risc PC support | A separate proposal targeting a legacy Arm-based system | Removal is only proposed; adoption is undecided |
This table does not compare performance; it summarizes technical constraints and development status. The emulation targets four architectures, while the support-removal discussion concerns a single Arm-based system. The two share related technical constraints but do not refer directly to the same change. It would be wrong to read the added compare-and-exchange feature as ending support for any architecture as a whole.
Acorn Risc PC, named in the support-removal discussion
In his October 20 reply, McKenney said that in the pull request's note about ending support, the key word is "system," not "architecture." What he specifically meant was the Acorn Risc PC, whose removal Arnd Bergmann proposed. The question is not about ending support for the Arm instruction set as a whole, but about whether to keep supporting one specific old computer system.
Bergmann's removal proposal, submitted on September 8, describes technical circumstances that the compare-and-exchange patches alone do not reveal. The Acorn Risc PC debuted in 1994 with an ARM610 processor and later supported an upgrade to StrongARM. According to Bergmann, however, the system's CPU bus does not support 16-bit data transfers, and building the kernel requires specifying -march=armv3. Even if the CPU can be swapped for a newer one, the data transfer width the system's bus can handle does not change.
In addition, the -march=armv3 option was dropped in GCC 9, so maintaining Acorn Risc PC support means continuing to depend on the older GCC 8. This is a constraint that cannot be solved by compensating for missing hardware instructions in software. Continuing to support an old system requires maintaining not only kernel code but also the compilers and development environment needed to build it. This maintenance burden is one reason removal is being considered.
But a proposed removal is not the same as a decided one. In his October 20 note, McKenney said he recalled considerable opposition to the proposal. He also said he had not yet seen the removal patch in linux-next, the integration tree that gathers changes in development. He therefore said he did not know whether the proposal would be merged anytime soon, and no end date for Acorn Risc PC support has been set.
Better portability for generic code is a separate issue from maintaining legacy systems
If the patches make 2-byte compare-and-exchange available to generic code, kernel developers will find it easier to use the operation without worrying about per-CPU instruction differences. By extending the emulation already used for 1-byte compare-and-exchange to 2 bytes, architectures without dedicated instructions can handle the same operation. The main significance of the change is that it expands the set of operations generic kernel code can use and improves portability across architectures.
On the other hand, the emulation involves 4-byte compare-and-exchange operations and retries when needed. It therefore cannot be assumed that the change speeds up processing or reduces memory use. The pull request also includes no benchmark results showing performance benefits. Rather than any user-visible performance gain, the point is first that the range of operations available to generic kernel code grows.
The patches' adoption status also needs to be checked going forward. In a separate October 20 reply, McKenney said Linus Torvalds has not yet pulled the change. The compare-and-exchange patches for Linux 7.4 and the proposal to remove Acorn Risc PC support are independent changes, and their adoption must be tracked separately. Even if the compare-and-exchange emulation is merged, it will not by itself make every atomic operation available. When generic code adopts new algorithms in the future, developers will need to confirm that all required operations, including ordinary writes and not just compare-and-exchange, are available on each architecture.