Messages in this thread | | | Date | Thu, 25 Jun 2020 13:29:26 +0200 | From | Peter Zijlstra <> | Subject | Re: [rcu:rcu/next 35/35] kernel/rcu/tree.c:251:8: error: implicit declaration of function 'arch_atomic_add_return'; did you mean |
| |
On Thu, Jun 25, 2020 at 11:55:13AM +0200, Marco Elver wrote: > On Wed, 24 Jun 2020 at 22:30, Paul E. McKenney <paulmck@kernel.org> wrote:
> > diff --git a/include/linux/atomic-fallback.h b/include/linux/atomic-fallback.h > > index 2c4927b..b7935857 100644 > > --- a/include/linux/atomic-fallback.h > > +++ b/include/linux/atomic-fallback.h > > @@ -133,6 +133,7 @@ atomic_add_return(int i, atomic_t *v) > > return ret; > > } > > #define atomic_add_return atomic_add_return > > +#define arch_atomic_add_return atomic_add_return > > #endif > > > > #endif /* atomic_add_return_relaxed */ > > > > ------------------------------------------------------------------------ > > > > And of course similar for arch_atomic_andnot() and arch_atomic_read(). > > > > Another way would be to define a noinstr_atomic_add_return() that > > was defined something like this: > > > > ------------------------------------------------------------------------ > > > > #ifdef CONFIG_HAVE_ARCH_KCSAN > > # define noinstr_atomic_add_return arch_atomic_add_return > > #else > > # define noinstr_atomic_add_return atomic_add_return > > #endif > > noinstr also needs to apply to KASAN & co, so this won't quite work. > Every architecture that defines arch_atomic_* has #define ARCH_ATOMIC, > so that could be used instead.
Right. And my bad for forgetting arch_atomic_ isn't generally available :/
> > ------------------------------------------------------------------------ > > > > And again similarly for the others. > > > > Left to myself, I would take the second option just because it provably > > leaves unaltered anything that isn't using the new API. That said, > > there has to be a better Kconfig option to key this off of. > > > > Thoughts? > > I think 'arch_atomic_*' is already the noinstr variant, and your first > suggestion of adding arch-defines to atomic-fallback.h seems cleaner, > as it avoids introducing new interfaces. But that also depends on if > it's a one-off, only for RCU, or if the use of 'arch_atomic' > proliferates outside of arch/. My guess is that, unfortunately, other > places will want 'arch_atomic' as well eventually.
I fear the same. Let me see if I can quickly modify the atomic scripts to generate the required fallbacks.
| |