On Fri, 16 Aug 2019, Joel Fernandes wrote: > On Sat, Aug 17, 2019 at 05:10:59AM +0800, kbuild test robot wrote: > > tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git from-joel.2019.08.16a > > head: 01b0e4d3e0ac279b295bc06a3591f0b810b9908f > > commit: bda80ba9decc7a32413e88d2f070de180c4b76ab [143/172] rcu/tree: Add basic support for kfree_rcu() batching > > config: riscv-defconfig (attached as .config) > > compiler: riscv64-linux-gcc (GCC) 7.4.0 > > reproduce: > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > git checkout bda80ba9decc7a32413e88d2f070de180c4b76ab > > # save the attached .config to linux build tree > > GCC_VERSION=7.4.0 make.cross ARCH=riscv > > This seems to be a riscv issue: > > A call to '__compiletime_assert_2792' declared with attribute error: > BUILD_BUG failed > > Could riscv folks take a look at it? Why is using xchg() causing issues? The > xchg() is being done on a bool. sizeof(bool) = 1, and the only xchg() implementation that's currently present on all RISC-V in Linux is usable only on 32-bit types. SPARC, Microblaze, C-SKY, and Hexagon all look like they have the same limitation. You'll probably see similar build breakage for those platforms too. MIPS, OpenRISC, Xtensa, and SuperH have compatibility functions for the 8-bit and 16-bit cases. We could add those for RISC-V. However, they'll be slower than the 4- and 8-byte cases. This is both because there's more code involved, and because there's an increased risk of false-sharing. Can you use a u32 instead for xchg/cmpxchg operations like struct kfree_rcu_cpu.monitor_todo that are intended to be cross-platform? Based on a cursory glance through the tree, it looks like there's only one cross-platform driver that uses 'true' or 'false' with the kernel xchg/cmpxchg, and it uses an int as the underlying data type. I suppose one could typedef "xchg_bool" on a per-architecture basis, to be smallest type that makes sense to use in an xchg() or cmpxchg(). That might save some memory on architectures that have a fast 1-byte xchg()/cmpxchg(). But given the lack of users in the tree, I'm not sure it's worth the effort. - Paul
