<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in cmpxchg</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>1d78814d - locking/atomic: scripts: simplify raw_atomic*() definitions</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/scripts/atomic/fallbacks/cmpxchg#1d78814d</link>
        <description>locking/atomic: scripts: simplify raw_atomic*() definitionsCurrently each ordering variant has several potential definitions,with a mixture of preprocessor and C definitions, including severalcopies of its C prototype, e.g.| #if defined(arch_atomic_fetch_andnot_acquire)| #define raw_atomic_fetch_andnot_acquire arch_atomic_fetch_andnot_acquire| #elif defined(arch_atomic_fetch_andnot_relaxed)| static __always_inline int| raw_atomic_fetch_andnot_acquire(int i, atomic_t *v)| {|       int ret = arch_atomic_fetch_andnot_relaxed(i, v);|       __atomic_acquire_fence();|       return ret;| }| #elif defined(arch_atomic_fetch_andnot)| #define raw_atomic_fetch_andnot_acquire arch_atomic_fetch_andnot| #else| static __always_inline int| raw_atomic_fetch_andnot_acquire(int i, atomic_t *v)| {|       return raw_atomic_fetch_and_acquire(~i, v);| }| #endifMake this a bit simpler by defining the C prototype once, and writingthe various potential definitions as plain C code guarded by ifdeffery.For example, the above becomes:| static __always_inline int| raw_atomic_fetch_andnot_acquire(int i, atomic_t *v)| {| #if defined(arch_atomic_fetch_andnot_acquire)|         return arch_atomic_fetch_andnot_acquire(i, v);| #elif defined(arch_atomic_fetch_andnot_relaxed)|         int ret = arch_atomic_fetch_andnot_relaxed(i, v);|         __atomic_acquire_fence();|         return ret;| #elif defined(arch_atomic_fetch_andnot)|         return arch_atomic_fetch_andnot(i, v);| #else|         return raw_atomic_fetch_and_acquire(~i, v);| #endif| }Which is far easier to read. As we now always have a single copy of theC prototype wrapping all the potential definitions, we now have anobvious single location for kerneldoc comments.At the same time, the fallbacks for raw_atomic*_xhcg() are made to use&apos;new&apos; rather than &apos;i&apos; as the name of the new value. This is what theexisting fallback template used, and is more consistent with theraw_atomic{_try,}cmpxchg() fallbacks.There should be no functional change as a result of this patch.Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;Link: https://lore.kernel.org/r/20230605070124.3741859-24-mark.rutland@arm.com

            List of files:
            /linux-6.15/scripts/atomic/fallbacks/cmpxchg</description>
        <pubDate>Mon, 05 Jun 2023 07:01:20 +0000</pubDate>
        <dc:creator>Mark Rutland &lt;mark.rutland@arm.com&gt;</dc:creator>
    </item>
<item>
        <title>9257959a - locking/atomic: scripts: restructure fallback ifdeffery</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/scripts/atomic/fallbacks/cmpxchg#9257959a</link>
        <description>locking/atomic: scripts: restructure fallback ifdefferyCurrently the various ordering variants of an atomic operation aredefined in groups of full/acquire/release/relaxed ordering variants withsome shared ifdeffery and several potential definitions of each orderingvariant in different branches of the shared ifdeffery.As an ordering variant can have several potential definitions downdifferent branches of the shared ifdeffery, it can be painful for ahuman to find a relevant definition, and we don&apos;t have a good locationto place anything common to all definitions of an ordering variant (e.g.kerneldoc).Historically the grouping of full/acquire/release/relaxed orderingvariants was necessary as we filled in the missing atomics in the samenamespace as the architecture used. It would be easy to accidentallydefine one ordering fallback in terms of another ordering fallback withredundant barriers, and avoiding that would otherwise require a lot ofbaroque ifdeffery.With recent changes we no longer need to fill in the missing atomics inthe arch_atomic*_&lt;op&gt;() namespace, and only need to fill in theraw_atomic*_&lt;op&gt;() namespace. Due to this, there&apos;s no risk of anamespace collision, and we can define each raw_atomic*_&lt;op&gt; orderingvariant with its own ifdeffery checking for the arch_atomic*_&lt;op&gt;ordering variants.Restructure the fallbacks in this way, with each ordering variant havingits own ifdeffery of the form:| #if defined(arch_atomic_fetch_andnot_acquire)| #define raw_atomic_fetch_andnot_acquire arch_atomic_fetch_andnot_acquire| #elif defined(arch_atomic_fetch_andnot_relaxed)| static __always_inline int| raw_atomic_fetch_andnot_acquire(int i, atomic_t *v)| {| 	int ret = arch_atomic_fetch_andnot_relaxed(i, v);| 	__atomic_acquire_fence();| 	return ret;| }| #elif defined(arch_atomic_fetch_andnot)| #define raw_atomic_fetch_andnot_acquire arch_atomic_fetch_andnot| #else| static __always_inline int| raw_atomic_fetch_andnot_acquire(int i, atomic_t *v)| {| 	return raw_atomic_fetch_and_acquire(~i, v);| }| #endifNote that where there&apos;s no relevant arch_atomic*_&lt;op&gt;() orderingvariant, we&apos;ll define the operation in terms of a distinctraw_atomic*_&lt;otherop&gt;(), as this itself might have been filled in with afallback.As we now generate the raw_atomic*_&lt;op&gt;() implementations directly, weno longer need the trivial wrappers, so they are removed.This makes the ifdeffery easier to follow, and will allow for furtherimprovements in subsequent patches.There should be no functional change as a result of this patch.Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;Link: https://lore.kernel.org/r/20230605070124.3741859-21-mark.rutland@arm.com

            List of files:
            /linux-6.15/scripts/atomic/fallbacks/cmpxchg</description>
        <pubDate>Mon, 05 Jun 2023 07:01:17 +0000</pubDate>
        <dc:creator>Mark Rutland &lt;mark.rutland@arm.com&gt;</dc:creator>
    </item>
<item>
        <title>d12157ef - locking/atomic: make atomic*_{cmp,}xchg optional</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/scripts/atomic/fallbacks/cmpxchg#d12157ef</link>
        <description>locking/atomic: make atomic*_{cmp,}xchg optionalMost architectures define the atomic/atomic64 xchg and cmpxchgoperations in terms of arch_xchg and arch_cmpxchg respectfully.Add fallbacks for these cases and remove the trivial cases from archcode. On some architectures the existing definitions are kept as theseare used to build other arch_atomic*() operations.Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;Link: https://lore.kernel.org/r/20230605070124.3741859-5-mark.rutland@arm.com

            List of files:
            /linux-6.15/scripts/atomic/fallbacks/cmpxchg</description>
        <pubDate>Mon, 05 Jun 2023 07:01:01 +0000</pubDate>
        <dc:creator>Mark Rutland &lt;mark.rutland@arm.com&gt;</dc:creator>
    </item>
</channel>
</rss>
