On Tue, 05 May 2020 15:16:09 +0200
Thomas Gleixner <t...@linutronix.de> wrote:
> Currently instrumentation of atomic primitives is done at the
> architecture level, while composites or fallbacks are provided at the
> generic level.
>
> The result is that there are no uninstrumented variants of the
> fallbacks. Since there is now need of such (see the next patch),
Just a comment on the change log. Can we avoid saying "see the next patch"?
A few years from now, if we stumble on changes in this commit and need to
see that next patch, if something happened to lore, it may be difficult to
find what that next patch was. But saying that patch's subject, would be
just a simple search in the git history.
That said, looking at "the next patch" which is "x86/doublefault: Remove
memmove() call", does that patch really have a need for such?
-- Steve
> invert this ordering.
>
> Doing this means moving the instrumentation into the generic code as
> well as having (for now) two variants of the fallbacks.
>
> Notes:
>
> - the various *cond_read* primitives are not proper fallbacks
> and got moved into linux/atomic.c. No arch_ variants are
> generated because the base primitives smp_cond_load*()
> are instrumented.
>
> - once all architectures are moved over to arch_atomic_ we can remove
> one of the fallback variants and reclaim some 2300 lines.
>
> - atomic_{read,set}*() are no longer double-instrumented
>
> Reported-by: Thomas Gleixner <t...@linutronix.de>
> Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
> Signed-off-by: Thomas Gleixner <t...@linutronix.de>
> Cc: Mark Rutland <mark.rutl...@arm.com>
>
