Help with atomic fallback

Help with atomic fallback

[Jason Gunthorpe]

Hi Mark/Uros,

I hope one of you can help me unravel this, I'm trying to use
try_cmpxchg64_release() from driver code and 0-day is saying arc
compiles explode:

   In file included from include/linux/atomic.h:80,
                    from drivers/iommu/generic_pt/fmt/../pt_defs.h:17,
                    from drivers/iommu/generic_pt/fmt/iommu_template.h:35,
                    from drivers/iommu/generic_pt/fmt/iommu_armv8_4k.c:13:
   drivers/iommu/generic_pt/fmt/../pt_defs.h: In function 'pt_table_install64':
>> include/linux/atomic/atomic-arch-fallback.h:295:14: error: void value not ignored as it ought to be
     295 |         ___r = raw_cmpxchg64_release((_ptr), ___o, (_new)); \
         |              ^
   include/linux/atomic/atomic-instrumented.h:4937:9: note: in expansion of macro 'raw_try_cmpxchg64_release'
    4937 |         raw_try_cmpxchg64_release(__ai_ptr, __ai_oldp, __VA_ARGS__); \
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/iommu/generic_pt/fmt/../pt_defs.h:144:16: note: in expansion of macro 'try_cmpxchg64_release'
     144 |         return try_cmpxchg64_release(entryp, &old_entry, table_entry);

Which is immediately because of a typo in atomic-arch-fallback.h code gen:

#if defined(arch_cmpxchg64_release)
#define raw_cmpxchg64_release arch_cmpxchg64_release
#elif defined(arch_cmpxchg64_relaxed)
#define raw_cmpxchg64_release(...) \
	__atomic_op_release(arch_cmpxchg64, __VA_ARGS__)
#elif defined(arch_cmpxchg64)
#define raw_cmpxchg64_release arch_cmpxchg64
#else
extern void raw_cmpxchg64_release_not_implemented(void);
     ^^^^^^^^^^^^^^^^^^^^^

That should return int to make the compiler happy, but then it will
fail to link (I think, my cross compiler ICEs before it gets there)

However, arc defines:

static inline s64
arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
{

And I see a:

static __always_inline s64
raw_atomic64_cmpxchg_release(atomic64_t *v, s64 old, s64 new)
{
#if defined(arch_atomic64_cmpxchg_release)
	return arch_atomic64_cmpxchg_release(v, old, new);
#elif defined(arch_atomic64_cmpxchg_relaxed)
	__atomic_release_fence();
	return arch_atomic64_cmpxchg_relaxed(v, old, new);
#elif defined(arch_atomic64_cmpxchg)
	return arch_atomic64_cmpxchg(v, old, new);

Which seems to strongly imply that arc can do the cmpxchg64_release
primitive.

But I haven't been able to figure out what is expected here for
arch_atomic64 vs try_cmpxchg64 to guess what is missing part here :\

Any advice?

Thanks,
Jason

Re: Help with atomic fallback

[Uros Bizjak]

On Tue, Dec 3, 2024 at 1:39 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> Hi Mark/Uros,
>
> I hope one of you can help me unravel this, I'm trying to use
> try_cmpxchg64_release() from driver code and 0-day is saying arc
> compiles explode:
>
>    In file included from include/linux/atomic.h:80,
>                     from drivers/iommu/generic_pt/fmt/../pt_defs.h:17,
>                     from drivers/iommu/generic_pt/fmt/iommu_template.h:35,
>                     from drivers/iommu/generic_pt/fmt/iommu_armv8_4k.c:13:
>    drivers/iommu/generic_pt/fmt/../pt_defs.h: In function 'pt_table_install64':
> >> include/linux/atomic/atomic-arch-fallback.h:295:14: error: void value not ignored as it ought to be
>      295 |         ___r = raw_cmpxchg64_release((_ptr), ___o, (_new)); \
>          |              ^
>    include/linux/atomic/atomic-instrumented.h:4937:9: note: in expansion of macro 'raw_try_cmpxchg64_release'
>     4937 |         raw_try_cmpxchg64_release(__ai_ptr, __ai_oldp, __VA_ARGS__); \
>          |         ^~~~~~~~~~~~~~~~~~~~~~~~~
>    drivers/iommu/generic_pt/fmt/../pt_defs.h:144:16: note: in expansion of macro 'try_cmpxchg64_release'
>      144 |         return try_cmpxchg64_release(entryp, &old_entry, table_entry);
>
> Which is immediately because of a typo in atomic-arch-fallback.h code gen:
>
> #if defined(arch_cmpxchg64_release)
> #define raw_cmpxchg64_release arch_cmpxchg64_release
> #elif defined(arch_cmpxchg64_relaxed)
> #define raw_cmpxchg64_release(...) \
>         __atomic_op_release(arch_cmpxchg64, __VA_ARGS__)
> #elif defined(arch_cmpxchg64)
> #define raw_cmpxchg64_release arch_cmpxchg64
> #else
> extern void raw_cmpxchg64_release_not_implemented(void);
>      ^^^^^^^^^^^^^^^^^^^^^
>
> That should return int to make the compiler happy, but then it will
> fail to link (I think, my cross compiler ICEs before it gets there)
>
> However, arc defines:
>
> static inline s64
> arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
> {

Please note that arch_atomic64_cmpxchg() and arch_cmpxchg64() are two
different things.

> And I see a:
>
> static __always_inline s64
> raw_atomic64_cmpxchg_release(atomic64_t *v, s64 old, s64 new)
> {
> #if defined(arch_atomic64_cmpxchg_release)
>         return arch_atomic64_cmpxchg_release(v, old, new);
> #elif defined(arch_atomic64_cmpxchg_relaxed)
>         __atomic_release_fence();
>         return arch_atomic64_cmpxchg_relaxed(v, old, new);
> #elif defined(arch_atomic64_cmpxchg)
>         return arch_atomic64_cmpxchg(v, old, new);
>
> Which seems to strongly imply that arc can do the cmpxchg64_release
> primitive.

No, this is *atomic64* version. Arc has to define arch_cmpxchg64 in
its cmpxchg.h. An example can be seen in e.g.
arch/m68k/include/asm/cmpxchg.h [1], where we have:

#include <asm-generic/cmpxchg-local.h>

#define arch_cmpxchg64_local(ptr, o, n)
__generic_cmpxchg64_local((ptr), (o), (n))

#define arch_cmpxchg64(ptr, o, n) arch_cmpxchg64_local((ptr), (o), (n))

[1] https://elixir.bootlin.com/linux/v6.12.1/source/arch/m68k/include/asm/cmpxchg.h

> But I haven't been able to figure out what is expected here for
> arch_atomic64 vs try_cmpxchg64 to guess what is missing part here :\
>
> Any advice?

Please use system_has_cmpxchg64 define, as is the case in
source/mm/slab.h. Arc does not define arch_cmpxchg64() and should be
excluded from compilation.

Uros.

Re: Help with atomic fallback

[Mark Rutland]

On Mon, Dec 02, 2024 at 08:38:56PM -0400, Jason Gunthorpe wrote:
> Hi Mark/Uros,

Hi Jason,

> I hope one of you can help me unravel this, I'm trying to use
> try_cmpxchg64_release() from driver code and 0-day is saying arc
> compiles explode:
> 
>    In file included from include/linux/atomic.h:80,
>                     from drivers/iommu/generic_pt/fmt/../pt_defs.h:17,
>                     from drivers/iommu/generic_pt/fmt/iommu_template.h:35,
>                     from drivers/iommu/generic_pt/fmt/iommu_armv8_4k.c:13:
>    drivers/iommu/generic_pt/fmt/../pt_defs.h: In function 'pt_table_install64':
> >> include/linux/atomic/atomic-arch-fallback.h:295:14: error: void value not ignored as it ought to be
>      295 |         ___r = raw_cmpxchg64_release((_ptr), ___o, (_new)); \
>          |              ^
>    include/linux/atomic/atomic-instrumented.h:4937:9: note: in expansion of macro 'raw_try_cmpxchg64_release'
>     4937 |         raw_try_cmpxchg64_release(__ai_ptr, __ai_oldp, __VA_ARGS__); \
>          |         ^~~~~~~~~~~~~~~~~~~~~~~~~
>    drivers/iommu/generic_pt/fmt/../pt_defs.h:144:16: note: in expansion of macro 'try_cmpxchg64_release'
>      144 |         return try_cmpxchg64_release(entryp, &old_entry, table_entry);

I'm assuming that's the report at:

  https://lore.kernel.org/oe-kbuild-all/202411301219.jHkzXdJD-lkp@intel.com/

... for which the config is:

  https://download.01.org/0day-ci/archive/20241130/202411301219.jHkzXdJD-lkp@intel.com/config

> Which is immediately because of a typo in atomic-arch-fallback.h code gen:
> 
> #if defined(arch_cmpxchg64_release)
> #define raw_cmpxchg64_release arch_cmpxchg64_release
> #elif defined(arch_cmpxchg64_relaxed)
> #define raw_cmpxchg64_release(...) \
> 	__atomic_op_release(arch_cmpxchg64, __VA_ARGS__)
> #elif defined(arch_cmpxchg64)
> #define raw_cmpxchg64_release arch_cmpxchg64
> #else
> extern void raw_cmpxchg64_release_not_implemented(void);
>      ^^^^^^^^^^^^^^^^^^^^^

This means that arc isn't providing a suitable defintion to build
raw_cmpxchg64_release() from, or for some reason the header includes up
to this point haven't included the relevant definition.

From the ifdeffery, there's no definition of:

  arch_cmpxchg64_release
  arch_cmpxchg64_relaxed
  arch_cmpxchg64

... and hence no way to build raw_cmpxchg64_release().

The intent here is to have a build failure at point of use, since some
architectures do not or cannot provide these, but we should clean this
up to be clearer. The mismatch is intentional and this isn't a typo, but
I agree it's not great.

> That should return int to make the compiler happy, but then it will
> fail to link (I think, my cross compiler ICEs before it gets there)
> 
> However, arc defines:
> 
> static inline s64
> arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
> {
>
> And I see a:
> 
> static __always_inline s64
> raw_atomic64_cmpxchg_release(atomic64_t *v, s64 old, s64 new)
> {
> #if defined(arch_atomic64_cmpxchg_release)
> 	return arch_atomic64_cmpxchg_release(v, old, new);
> #elif defined(arch_atomic64_cmpxchg_relaxed)
> 	__atomic_release_fence();
> 	return arch_atomic64_cmpxchg_relaxed(v, old, new);
> #elif defined(arch_atomic64_cmpxchg)
> 	return arch_atomic64_cmpxchg(v, old, new);
> 
> Which seems to strongly imply that arc can do the cmpxchg64_release
> primitive.
> 
> But I haven't been able to figure out what is expected here for
> arch_atomic64 vs try_cmpxchg64 to guess what is missing part here :\

In this case I think this is an oversight in the arc code, and arc *can*
provide a definition of arch_cmpxchg64(), as per the hack below (which
implicilty provides arch_atomic64_cmpxchg*()):

| diff --git a/arch/arc/include/asm/atomic64-arcv2.h b/arch/arc/include/asm/atomic64-arcv2.h
| index 9b5791b854713..ce3fdcb48b0f9 100644
| --- a/arch/arc/include/asm/atomic64-arcv2.h
| +++ b/arch/arc/include/asm/atomic64-arcv2.h
| @@ -137,12 +137,10 @@ ATOMIC64_OPS(xor, xor, xor)
|  #undef ATOMIC64_OP_RETURN
|  #undef ATOMIC64_OP
|  
| -static inline s64
| -arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
| +static inline u64
| +__arch_cmpxchg64_relaxed(volatile void *ptr, u64 old, u64 new)
|  {
| -       s64 prev;
| -
| -       smp_mb();
| +       u64 prev;
|  
|         __asm__ __volatile__(
|         "1:     llockd  %0, [%1]        \n"
| @@ -152,14 +150,12 @@ arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
|         "       bnz     1b              \n"
|         "2:                             \n"
|         : "=&r"(prev)
| -       : "r"(ptr), "ir"(expected), "r"(new)
| -       : "cc");        /* memory clobber comes from smp_mb() */
| -
| -       smp_mb();
| +       : "r"(ptr), "ir"(old), "r"(new)
| +       : "memory", "cc");
|  
|         return prev;
|  }
| -#define arch_atomic64_cmpxchg arch_atomic64_cmpxchg
| +#define arch_cmpxchg64_relaxed __arch_cmpxchg64_relaxed
|  
|  static inline s64 arch_atomic64_xchg(atomic64_t *ptr, s64 new)
|  {

However, there are other cases where cmpxchg64 doesn't exist or cannot
be used, and the existing (x86-specific) system_has_cmpxchg64() isn't
ideal. I suspect we need both a Kconfig symbol and a runtime check to
handle this properly.

I think if we fix up arc along the lines of the above (with xchg too,
and handled in the cmpxchg header), then we can rely on the Kconfig
check that the existing io-pgtable code has:

  depends on !GENERIC_ATOMIC64    # for cmpxchg64()

... and we'll (separately) need to figure out what to do for the runtime
system_has_cmpxchg64() check.

Mark.

Re: Help with atomic fallback

[Jason Gunthorpe]

On Tue, Dec 03, 2024 at 12:26:22PM +0000, Mark Rutland wrote:

> I'm assuming that's the report at:
> 
>   https://lore.kernel.org/oe-kbuild-all/202411301219.jHkzXdJD-lkp@intel.com/
> 
> ... for which the config is:
> 
>   https://download.01.org/0day-ci/archive/20241130/202411301219.jHkzXdJD-lkp@intel.com/config

Yeah, that is representative

> > Which is immediately because of a typo in atomic-arch-fallback.h code gen:
> > 
> > #if defined(arch_cmpxchg64_release)
> > #define raw_cmpxchg64_release arch_cmpxchg64_release
> > #elif defined(arch_cmpxchg64_relaxed)
> > #define raw_cmpxchg64_release(...) \
> > 	__atomic_op_release(arch_cmpxchg64, __VA_ARGS__)
> > #elif defined(arch_cmpxchg64)
> > #define raw_cmpxchg64_release arch_cmpxchg64
> > #else
> > extern void raw_cmpxchg64_release_not_implemented(void);
> >      ^^^^^^^^^^^^^^^^^^^^^
> 
> This means that arc isn't providing a suitable defintion to build
> raw_cmpxchg64_release() from, or for some reason the header includes up
> to this point haven't included the relevant definition.
> 
> From the ifdeffery, there's no definition of:
> 
>   arch_cmpxchg64_release
>   arch_cmpxchg64_relaxed
>   arch_cmpxchg64
> 
> ... and hence no way to build raw_cmpxchg64_release().
> 
> The intent here is to have a build failure at point of use, since some
> architectures do not or cannot provide these, but we should clean this
> up to be clearer. The mismatch is intentional and this isn't a typo, but
> I agree it's not great.

It is not consistent..

For instance on ARC io-pgtable-arm.c compiles OK it calls:

	old = cmpxchg64_relaxed(ptep, curr, new);

Which expands to:

 old = ({ typeof(ptep) __ai_ptr = (ptep); instrument_atomic_read_write(__ai_ptr, sizeof(*__ai_ptr)); raw_cmpxchg64_relaxed_not_implemented(); });

And no compiler error. Presumably it doesn't link, but my compiler
ICE's before it gets that far.

> In this case I think this is an oversight in the arc code, and arc *can*
> provide a definition of arch_cmpxchg64(), as per the hack below (which
> implicilty provides arch_atomic64_cmpxchg*()):
> 
> | diff --git a/arch/arc/include/asm/atomic64-arcv2.h b/arch/arc/include/asm/atomic64-arcv2.h
> | index 9b5791b854713..ce3fdcb48b0f9 100644
> | --- a/arch/arc/include/asm/atomic64-arcv2.h
> | +++ b/arch/arc/include/asm/atomic64-arcv2.h
> | @@ -137,12 +137,10 @@ ATOMIC64_OPS(xor, xor, xor)
> |  #undef ATOMIC64_OP_RETURN
> |  #undef ATOMIC64_OP
> |  
> | -static inline s64
> | -arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
> | +static inline u64
> | +__arch_cmpxchg64_relaxed(volatile void *ptr, u64 old, u64 new)
> |  {
> | -       s64 prev;
> | -
> | -       smp_mb();
> | +       u64 prev;
> |  
> |         __asm__ __volatile__(
> |         "1:     llockd  %0, [%1]        \n"
> | @@ -152,14 +150,12 @@ arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
> |         "       bnz     1b              \n"
> |         "2:                             \n"
> |         : "=&r"(prev)
> | -       : "r"(ptr), "ir"(expected), "r"(new)
> | -       : "cc");        /* memory clobber comes from smp_mb() */
> | -
> | -       smp_mb();
> | +       : "r"(ptr), "ir"(old), "r"(new)
> | +       : "memory", "cc");
> |  
> |         return prev;
> |  }
> | -#define arch_atomic64_cmpxchg arch_atomic64_cmpxchg
> | +#define arch_cmpxchg64_relaxed __arch_cmpxchg64_relaxed
> |  
> |  static inline s64 arch_atomic64_xchg(atomic64_t *ptr, s64 new)
> |  {

Okay, that is what I was expecting to find, so I can ping the arc
folks on this direction and maybe get this resolved.. I'll send the
above to them as a patch to start a discussion

> However, there are other cases where cmpxchg64 doesn't exist or cannot
> be used, and the existing (x86-specific) system_has_cmpxchg64() isn't
> ideal. I suspect we need both a Kconfig symbol and a runtime check to
> handle this properly.

> I think if we fix up arc along the lines of the above (with xchg too,
> and handled in the cmpxchg header), then we can rely on the Kconfig
> check that the existing io-pgtable code has:
> 
>   depends on !GENERIC_ATOMIC64    # for cmpxchg64()

Yes, I have been relying on this as it seems the closest thing we have
today.

> ... and we'll (separately) need to figure out what to do for the runtime
> system_has_cmpxchg64() check.

It is gross, but at least today we can do as slab does and #ifdef
system_has_cmpxchg64

Thanks,
Jason

Re: Help with atomic fallback

[Mark Rutland]

On Tue, Dec 03, 2024 at 09:08:48AM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 03, 2024 at 12:26:22PM +0000, Mark Rutland wrote:
> 
> > I'm assuming that's the report at:
> > 
> >   https://lore.kernel.org/oe-kbuild-all/202411301219.jHkzXdJD-lkp@intel.com/
> > 
> > ... for which the config is:
> > 
> >   https://download.01.org/0day-ci/archive/20241130/202411301219.jHkzXdJD-lkp@intel.com/config
> 
> Yeah, that is representative
> 
> > > Which is immediately because of a typo in atomic-arch-fallback.h code gen:
> > > 
> > > #if defined(arch_cmpxchg64_release)
> > > #define raw_cmpxchg64_release arch_cmpxchg64_release
> > > #elif defined(arch_cmpxchg64_relaxed)
> > > #define raw_cmpxchg64_release(...) \
> > > 	__atomic_op_release(arch_cmpxchg64, __VA_ARGS__)
> > > #elif defined(arch_cmpxchg64)
> > > #define raw_cmpxchg64_release arch_cmpxchg64
> > > #else
> > > extern void raw_cmpxchg64_release_not_implemented(void);
> > >      ^^^^^^^^^^^^^^^^^^^^^
> > 
> > This means that arc isn't providing a suitable defintion to build
> > raw_cmpxchg64_release() from, or for some reason the header includes up
> > to this point haven't included the relevant definition.
> > 
> > From the ifdeffery, there's no definition of:
> > 
> >   arch_cmpxchg64_release
> >   arch_cmpxchg64_relaxed
> >   arch_cmpxchg64
> > 
> > ... and hence no way to build raw_cmpxchg64_release().
> > 
> > The intent here is to have a build failure at point of use, since some
> > architectures do not or cannot provide these, but we should clean this
> > up to be clearer. The mismatch is intentional and this isn't a typo, but
> > I agree it's not great.
> 
> It is not consistent..
> 
> For instance on ARC io-pgtable-arm.c compiles OK it calls:
> 
> 	old = cmpxchg64_relaxed(ptep, curr, new);
> 
> Which expands to:
> 
>  old = ({ typeof(ptep) __ai_ptr = (ptep); instrument_atomic_read_write(__ai_ptr, sizeof(*__ai_ptr)); raw_cmpxchg64_relaxed_not_implemented(); });
> 
> And no compiler error. Presumably it doesn't link, but my compiler
> ICE's before it gets that far.

I don't think that "my compiler ICE's" implies "compiles OK".

When building io-pgtable-arm.c for ARC (with your tree!) I see the same error:

| [mark@lakrids:~/src/linux]% git describe HEAD
| v6.13-rc1-19-gf81fe181dcfff
| [mark@lakrids:~/src/linux]% usekorg 13.2.0 make ARCH=arc CROSS_COMPILE=arc-linux- drivers/iommu/io-pgtable-arm.o 
|   CC      kernel/bounds.s
|   CC      arch/arc/kernel/asm-offsets.s
|   CALL    scripts/checksyscalls.sh
|   CC      drivers/iommu/io-pgtable-arm.o
| drivers/iommu/io-pgtable-arm.c: In function 'arm_lpae_install_table':
| drivers/iommu/io-pgtable-arm.c:387:13: error: void value not ignored as it ought to be
|   387 |         old = cmpxchg64_relaxed(ptep, curr, new);
|       |             ^
| make[4]: *** [scripts/Makefile.build:194: drivers/iommu/io-pgtable-arm.o] Error 1
| make[3]: *** [scripts/Makefile.build:440: drivers/iommu] Error 2
| make[2]: *** [scripts/Makefile.build:440: drivers] Error 2
| make[1]: *** [/home/mark/src/linux/Makefile:1989: .] Error 2
| make: *** [Makefile:251: __sub-make] Error 2

... so I suspect whatever is causing your toolchain to ICE is masking
that, and (AFAICT) the error is consistent.

Note that per drivers/iommu/{Kconfig,Makefile}, if you build with
CONFIG_GENERIC_ATOMIC64=y, then CONFIG_IOMMU_IO_PGTABLE_LPAE=n and so
io-pgtable-arm.o won't actually be built.

FWIW, I'm using the cross toolchains from:

  https://mirrors.edge.kernel.org/pub/tools/crosstool/

> > In this case I think this is an oversight in the arc code, and arc *can*
> > provide a definition of arch_cmpxchg64(), as per the hack below (which
> > implicilty provides arch_atomic64_cmpxchg*()):
> > 
> > | diff --git a/arch/arc/include/asm/atomic64-arcv2.h b/arch/arc/include/asm/atomic64-arcv2.h
> > | index 9b5791b854713..ce3fdcb48b0f9 100644
> > | --- a/arch/arc/include/asm/atomic64-arcv2.h
> > | +++ b/arch/arc/include/asm/atomic64-arcv2.h
> > | @@ -137,12 +137,10 @@ ATOMIC64_OPS(xor, xor, xor)
> > |  #undef ATOMIC64_OP_RETURN
> > |  #undef ATOMIC64_OP
> > |  
> > | -static inline s64
> > | -arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
> > | +static inline u64
> > | +__arch_cmpxchg64_relaxed(volatile void *ptr, u64 old, u64 new)
> > |  {
> > | -       s64 prev;
> > | -
> > | -       smp_mb();
> > | +       u64 prev;
> > |  
> > |         __asm__ __volatile__(
> > |         "1:     llockd  %0, [%1]        \n"
> > | @@ -152,14 +150,12 @@ arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
> > |         "       bnz     1b              \n"
> > |         "2:                             \n"
> > |         : "=&r"(prev)
> > | -       : "r"(ptr), "ir"(expected), "r"(new)
> > | -       : "cc");        /* memory clobber comes from smp_mb() */
> > | -
> > | -       smp_mb();
> > | +       : "r"(ptr), "ir"(old), "r"(new)
> > | +       : "memory", "cc");
> > |  
> > |         return prev;
> > |  }
> > | -#define arch_atomic64_cmpxchg arch_atomic64_cmpxchg
> > | +#define arch_cmpxchg64_relaxed __arch_cmpxchg64_relaxed
> > |  
> > |  static inline s64 arch_atomic64_xchg(atomic64_t *ptr, s64 new)
> > |  {
> 
> Okay, that is what I was expecting to find, so I can ping the arc
> folks on this direction and maybe get this resolved.. I'll send the
> above to them as a patch to start a discussion

Cool; please Cc me for that.

Mark.

Re: Help with atomic fallback

[Jason Gunthorpe]

On Tue, Dec 03, 2024 at 02:40:15PM +0000, Mark Rutland wrote:
> > Which expands to:
> > 
> >  old = ({ typeof(ptep) __ai_ptr = (ptep); instrument_atomic_read_write(__ai_ptr, sizeof(*__ai_ptr)); raw_cmpxchg64_relaxed_not_implemented(); });
> > 
> > And no compiler error. Presumably it doesn't link, but my compiler
> > ICE's before it gets that far.
> 
> I don't think that "my compiler ICE's" implies "compiles OK".

Well, it ICE's later. I'm using the 0-day instructions with
make.cross

during RTL pass: mach
../drivers/iommu/of_iommu.c: In function 'of_iommu_configure':
../drivers/iommu/of_iommu.c:163:1: internal compiler error: in arc_ifcvt, at config/arc/arc.cc:9703
  163 | }
      | ^

> When building io-pgtable-arm.c for ARC (with your tree!) I see the same error:

Okay, I think I see it too, it got lost in all the other noise :\

Jason