[paulmckrcu:cmpxchg2.2026.09.22a 25/28] arch/arc/include/asm/cmpxchg.h:46:58: error: pointer type mismatch in conditional expression
Paul E. McKenney
paulmck at kernel.org
Tue Sep 29 13:47:12 PDT 2026
On Thu, Sep 24, 2026 at 02:27:11PM -0700, Vineet Gupta wrote:
> On 9/24/26 13:58, Bradley Morgan wrote:
> > On 24 September 2026 21:52:55 BST, Vineet Gupta <vgupta at kernel.org> wrote:
> > > On 9/24/26 00:51, kernel test robot wrote:
> > > > tree: https://github.com/paulmckrcu/linux cmpxchg2.2026.09.22a
> > > > head: 54c282c15475ebfae4712fe3ab637c9d19c723d6
> > > > commit: b6d4f6af38f85e7948fd64f9bf09cbb858b4dade [25/28] ARC: Emulate
> > > two-byte cmpxchg
> > > > config: arc-allyesconfig
> > > (https://download.01.org/0day-ci/archive/20260924/202609241517.SSV1Goz3-lkp@intel.com/config)
> > > > compiler: arc-linux-gcc (GCC) 16.1.0
> > > > reproduce (this is a W=1 build):
> > > (https://download.01.org/0day-ci/archive/20260924/202609241517.SSV1Goz3-lkp@intel.com/reproduce)
> > > > If you fix the issue in a separate patch/commit (i.e. not just a new
> > > version of
> > > > the same patch/commit), kindly add following tags
> > > > | Reported-by: kernel test robot <lkp at intel.com>
> > > > | Closes:
> > > https://lore.kernel.org/oe-kbuild-all/202609241517.SSV1Goz3-lkp@intel.com/
> > > > All errors (new ones prefixed by >>):
> > > >
> > > > In file included from arch/arc/include/asm/atomic.h:13,
> > > > from include/linux/atomic.h:7,
> > > > from include/asm-generic/bitops/lock.h:5,
> > > > from arch/arc/include/asm/bitops.h:190,
> > > > from include/linux/bitops.h:67,
> > > > from include/linux/log2.h:12,
> > > > from include/asm-generic/div64.h:55,
> > > > from ./arch/arc/include/generated/asm/div64.h:1,
> > > > from include/linux/math.h:6,
> > > > from include/linux/math64.h:6,
> > > > from include/linux/time.h:6,
> > > > from include/linux/stat.h:19,
> > > > from include/linux/fs_dirent.h:5,
> > > > from include/linux/fs/super_types.h:5,
> > > > from include/linux/fs/super.h:5,
> > > > from include/linux/fs.h:5,
> > > > from include/linux/fscrypt.h:16,
> > > > from fs/crypto/fscrypt_private.h:15,
> > > > from fs/crypto/hooks.c:10:
> > > > fs/crypto/hooks.c: In function 'fscrypt_get_symlink':
> > > > > > arch/arc/include/asm/cmpxchg.h:46:58: error: pointer type mismatch in
> > > conditional expression [-Wincompatible-pointer-types]
> > > > 46 | unsigned long _new_ = (unsigned long)(0 ? *(_p_) :
> > > (new)); \
> > >
> > > Issue is in fs/crypto/hooks.c doing cmpxchg_release(&inode->i_link, NULL,
> > > pstr.name)
> > > where i_link is char * and pstr.name is unsigned char *),
> > >
> > > The problem is when pointer types are incompatible and that's exactly the
> > > W toggle above.
> > >
> > > So Bradley's patch needs this fixup
> > >
> > > diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
> > > index 4596edfefa95..9053098bb152 100644
> > > --- a/arch/arc/include/asm/cmpxchg.h
> > > +++ b/arch/arc/include/asm/cmpxchg.h
> > > @@ -42,8 +42,10 @@
> > > #define arch_cmpxchg_relaxed(ptr, old, new) \
> > > ({ \
> > > __typeof__(ptr) _p_ = (ptr); \
> > > - unsigned long _old_ = (unsigned long)(0 ? *(_p_) : (old)); \
> > > - unsigned long _new_ = (unsigned long)(0 ? *(_p_) : (new)); \
> > > + __typeof__(*(ptr)) _o_ = (old); \
> > > + __typeof__(*(ptr)) _n_ = (new); \
> > > + unsigned long _old_ = (unsigned long)_o_; \
> > > + unsigned long _new_ = (unsigned long)_n_; \
> > >
> > > P.S: For arch changes shouldn't the submitter be required to at least test
> > > the building, specially when this involves the macro maze. Its really easy
> > > with crosstool hosting all the cross-compilers [1] - just download and
> > > untar.
> > >
> > > [1]
> > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/16.2.0/
> > Well thanks but I didn't have a proper server till yesterday.
>
> A relatively decent laptop works for me.
And you will get *way* faster response time than waiting on kernel
test robot. ;-)
> > I'll post all arch patches when Paul tells me how he wants it
>
> Please do a minimal compile build - it will save you the re-spins.
>
> > Like if he wants u16 in first then arch changes sent.
First, I queued Vineet's cmpxchg patch from his pull request to Linus.
I have marked it "EXP" so that I don't accidentally ship it off somewhere
myself.
Given the surprises from the u8/u16 changes, I suggest the following:
1. One patch to add cmpxchg_emu_u16(), but without the u8/u16
changes. And without the CONFIG_ARCH_NEED_CMPXCHG_1_2_EMU
change.
At Bradley's option, cmpxchg_emu_u8() could remain as is, with
cmpxchg_emu_u16() being born as u16. The upside is less churn
later. The downside is that more up-front testing is needed,
and thus greater interaction with busy architecture maintainers.
If it was me, I would start with cmpxchg_emu_u16() being as
close to cmpxchg_emu_u8() as possible in order to "get the
camel's nose into the tent" as quickly and easily as possible.
But this is Bradley's patch series, so his choice.
2. One patch each to add use of cmpxchg_emu_u16() to each
affected architecture.
3. Given #1, each patch for #2 can go in independently. The patches
for #2 of course need acks from their respective maintainers.
4. A patch to rename CONFIG_ARCH_NEED_CMPXCHG_1_EMU to
CONFIG_ARCH_NEED_CMPXCHG_1_2_EMU. This will cross lib and
architectures, which should be OK because it is just a name
change. We collect acks as before.
5. Convert cmpxchg_emu_u8() away from uintptr_t, and, if needed,
cmpxchg_emu_u16() as well.
This could take a merge window or three to get in, but that is not all
that bad for cross-architecture patch serieses such as this one.
Bradley, Vineet, thoughts?
Thanx, Paul
More information about the linux-snps-arc
mailing list