Re: [paulmckrcu:cmpxchg2.2026.09.22a 25/28] arch/arc/include/asm/cmpxchg.h:46:58: error: pointer type mismatch in conditional expression
Bradley Morgan
brads at mainlining.org
Tue Sep 29 23:39:02 PDT 2026
On 29 September 2026 23:10:01 BST, Vineet Gupta <vgupta at kernel.org> 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 ;-)
Hmm, I'd prefer to leave u16 as is, I'll send the rename patch in the
coming hours/days, I have school
>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.
>
>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.
>
>Thx,
>-Vineet
>
--- Thanks!
"I'm not a very positive person" - Linus torvalds
More information about the linux-snps-arc
mailing list