On Wed, Jan 08, 2025 at 12:30:27PM -0800, Linus Torvalds wrote:
> On Wed, 8 Jan 2025 at 12:13, Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote:
> >
> > Yes, we also noticed during development that try_cmpxchg_tail (in
> > patch 9) couldn't rely on 16-bit cmpxchg being available everywhere
>
> I think that's purely a "we have had no use for it" issue.
>
> A 16-bit cmpxchg can always be written using a larger size, and we did
> that for 8-bit ones for RCU.
>
> See commit d4e287d7caff ("rcu-tasks: Remove open-coded one-byte
> cmpxchg() emulation") which switched RCU over to use a "native" 8-bit
> cmpxchg, because Paul had added the capability to all architectures,
> sometimes using a bigger size and "emulating" it: a88d970c8bb5 ("lib:
> Add one-byte emulation function").
Glad you liked it. ;-)
> In fact, I think that series added a couple of 16-bit cases too, but I
> actually went "if we have no users, don't bother".
Not only that, there were still architectures supported by the Linux
kernel that lacked 16-bit store instructions. Although this does not
make 16-bit emulation useless, it does give it some nasty sharp edges
in the form of compilers turning those 16-bit stores into non-atomic
RMW instructions. Or tearing them into 8-bit stores.
So yes, I dropped 16-bit emulated cmpxchg() from later versions of that
patch series.
When support for those architectures are dropped, I would be happy to do
the honors for 16-bit cmpxchg() emulation. Or to review someone else's
doing the honors, for that matter. ;-)
Thanx, Paul
