On Thu, 14 Dec 2023 12:32:38 -0800 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 14 Dec 2023 at 12:30, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Read my email. Don't do random x86-centric things. We have that > > > > #ifndef system_has_cmpxchg64 > > #define system_has_cmpxchg64() false > > #endif > > > > which should work. > > And again, by "should work" I mean that it would disable this entirely > on things like arm32 until the arm people decide they care. But at > least it won't use an unsafe non-working 64-bit cmpxchg. If archs have no implementation of cmpxchg64 then the code cannot be removed. If it's just slower and emulated, then it shouldn't be a big deal. The only thing it may lose is tracing in NMI context, which I'm not sure that really matters. > > And no, for 6.7, only fix reported bugs. No big reorgs at all, > particularly for something that likely has never been hit by any user > and sounds like this all just came out of discussion. The discussion came out of adding new tests to cover new changes I'm making in the ring buffer code that happened to trigger subtle bugs in the 32-bit version of reading the 64-bit timestamps. The reason for that code, is because of the 64-bit cmpcxhg that is required to implement it. If we are keeping this code, then there's 2 or 3 fixes to it that I need to send to you, and also one outstanding one that in theory can be a bug, but in practice is highly unlikely to ever be hit. The fix for that one is a bit more involved, and will have to come later. When I was discussing these fixes and other changes with Mathieu, we started thinking "is this complexity worth it?" and "does anything actually need this?". That's where this patch originated from. Now, I could also make this special code only compile for the "!system_has_cmpxchg64" case as well, which shouldn't punish the Atom processor to do 3 cmpxchg's instead of one cmpxchg8b. -- Steve
