On Wed, Jun 01, 2022 at 12:26:27PM +0200, Toke Høiland-Jørgensen wrote: > Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> writes: > > > On Mon, May 23, 2022 at 12:30:14PM +0200, Toke Høiland-Jørgensen wrote: > >> kernel test robot <lkp@xxxxxxxxx> writes: > >> > >> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > >> > head: eaea45fc0e7b6ae439526b4a41d91230c8517336 > >> > commit: 782347b6bcad07ddb574422e01e22c92e05928c8 xdp: Add proper __rcu annotations to redirect map entries > >> > date: 11 months ago > >> > config: ia64-randconfig-s031-20220522 (https://download.01.org/0day-ci/archive/20220522/202205222029.xpW3PM1y-lkp@xxxxxxxxx/config) > >> > compiler: ia64-linux-gcc (GCC) 11.3.0 > >> > >> Hmm, so this is ia64-only? Some kind of macro breakage? Paul, any ideas? > > > > Hi, > > > > It's surely IA64's cmpxchg() which contains lines like: > > _r_ = ia64_cmpxchg8_##sem((__u64 *) ptr, new, _o_); > > Oh, right. Hmm, well, if the cmpxchg does an internal cast that > complicates things a bit. My immediate thought was to move the > unrcu_pointer() inside the calls to cmpxchg(), like: > But that seems to confuse sparse because these are ptr-to-ptr > constructs: Yes, that can't work because it applies on the wrong level (same difference as between "int const ** ptr" and "int * const * ptr"). I've taken a quick look and the problem is really to be solved in IA64's macros for cmpxchg() and friends. Two things need to be done: 1) avoid casts like the "(__u64 *) ptr" here above (ideally no cast would be needed but a "(__u64 __force *) ptr" would be pefectly acceptable in such macros. 2) the value returned by these macros must match the type of the pointer and the old/new values. For example, on x86 such macros are written as: ({ __typeof__ (*(ptr)) __ret = (arg); switch (sizeof(*(ptr))) { case ... ... use ptr without dropping the address space .. __ret; )} See, for example, arch/x86/include/asm/cmpxchg.h -- Luc