[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
Wed Sep 30 10:55:25 PDT 2026
On Tue, Sep 29, 2026 at 03:10:01PM -0700, Vineet Gupta wrote:
>
>
> On 9/29/26 13:47, Paul E. McKenney wrote:
> > 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?
>
> Sound like a plan, buy hey its Bradley doing all the work here ;-)
I figured that I should give him the chance, but yes, if he declines I
will of course do any needed additional work.
> I would only add something I mentioned before: download the cross toolchains
> and do some build testing locally before posting. This is not because arch
> maintainers are busy or lazy (although they can be both) - that saves
> potential respins induced by new code or even broken existing code exposed.
Agreed!!!
> And on that topic I just found a gcc 16 ICE when building an allyesconfig
> for ARC. I will only be able to post the gcc fix after LPC, but just FYI in
> case someone runs into it.
Thanks for the heads up.
Thanx, Paul
More information about the linux-snps-arc
mailing list