From: Paul Walmsley <paul.walmsley@sifive.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: kbuild test robot <lkp@intel.com>,
Palmer Dabbelt <palmer@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
atishp04@gmail.com, rcu@vger.kernel.org, paulmck@linux.ibm.com,
kbuild-all@01.org, linux-kernel@vger.kernel.org
Subject: Re: [rcu:from-joel.2019.08.16a 143/172] kernel/rcu/tree.c:2808:6: note: in expansion of macro 'xchg'
Date: Fri, 16 Aug 2019 20:10:19 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.9999.1908161931110.32497@viisi.sifive.com> (raw)
In-Reply-To: <20190817010902.GB89926@google.com>
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
prev parent reply other threads:[~2019-08-17 3:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 21:10 [rcu:from-joel.2019.08.16a 143/172] kernel/rcu/tree.c:2808:6: note: in expansion of macro 'xchg' kbuild test robot
2019-08-17 1:04 ` Joel Fernandes
2019-08-17 1:09 ` Joel Fernandes
2019-08-17 3:10 ` Paul Walmsley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.9999.1908161931110.32497@viisi.sifive.com \
--to=paul.walmsley@sifive.com \
--cc=aou@eecs.berkeley.edu \
--cc=atishp04@gmail.com \
--cc=joel@joelfernandes.org \
--cc=kbuild-all@01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=palmer@sifive.com \
--cc=paulmck@linux.ibm.com \
--cc=rcu@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).