[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiWxnjFkqG9VLm0N3Nj4U7Y3JNvyshmjdwdD_=7_zZriw@mail.gmail.com>
Date: Wed, 8 Jan 2025 12:30:27 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kumar Kartikeya Dwivedi <memxor@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, Waiman Long <llong@...hat.com>,
Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Martin KaFai Lau <martin.lau@...nel.org>,
Eduard Zingerman <eddyz87@...il.com>, "Paul E. McKenney" <paulmck@...nel.org>, Tejun Heo <tj@...nel.org>,
Barret Rhoden <brho@...gle.com>, Josh Don <joshdon@...gle.com>, Dohyun Kim <dohyunkim@...gle.com>,
kernel-team@...a.com
Subject: Re: [PATCH bpf-next v1 00/22] Resilient Queued Spin Lock
On Wed, 8 Jan 2025 at 12:13, Kumar Kartikeya Dwivedi <memxor@...il.com> 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").
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".
Linus
Powered by blists - more mailing lists