* Re: powerpc/xmon: Relax frame size for clang
From: Michael Ellerman @ 2018-11-01 12:46 UTC (permalink / raw)
To: Joel Stanley, Naveen N . Rao, linuxppc-dev; +Cc: Nick Desaulniers
In-Reply-To: <20181031010934.3627-1-joel@jms.id.au>
On Wed, 2018-10-31 at 01:09:34 UTC, Joel Stanley wrote:
> When building with clang (8 trunk, 7.0 release) the frame size limit is
> hit:
>
> arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
> bytes in function 'xmon_core' [-Wframe-larger-than=]
>
> Some investigation by Naveen indicates this is due to clang saving the
> addresses to printf format strings on the stack.
>
> While this issue is investigated, bump up the frame size limit for xmon
> when building with clang.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/252
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9c87156cce5a63735d1218f0096a65
cheers
^ permalink raw reply
* Re: selftests/powerpc: Fix compilation issue due to asm label
From: Michael Ellerman @ 2018-11-01 12:46 UTC (permalink / raw)
To: Naveen N. Rao, Breno Leitao; +Cc: linuxppc-dev
In-Reply-To: <20181031171813.8970-1-naveen.n.rao@linux.vnet.ibm.com>
On Wed, 2018-10-31 at 17:18:13 UTC, "Naveen N. Rao" wrote:
> We are using 'dscr_insn' as a label in inline asm to identify if a
> SIGILL was generated by the mtspr instruction at that point. However,
> with inline assembly, the compiler is still free to duplicate the asm
> statement for optimization purposes, which results in the label being
> defined twice with the error:
> /tmp/ccerQCql.s:874: Error: symbol `dscr_insn' is already defined
>
> With different compiler versions, we may also see:
> /tmp/ccJzLDlN.o:(.toc+0x0): undefined reference to `dscr_insn'
>
> Remove the use of the label in the inline assembly. Instead, just look
> for the offending instruction in the signal handler.
>
> Reported-by: Breno Leitao <leitao@debian.org>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Tested-by: Breno Leitao <leitao@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1936f094e164cc13ebf17aba1d6b34
cheers
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Mark Rutland @ 2018-11-01 13:18 UTC (permalink / raw)
To: Trond Myklebust
Cc: linux-mips@linux-mips.org, linux-nfs@vger.kernel.org,
arnd@arndb.de, Peter Zijlstra, jhogan@kernel.org, Boqun Feng,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, davem@davemloft.net, bfields@fieldses.org,
paul.burton@mips.com, paulus@samba.org, netdev@vger.kernel.org,
Will Deacon, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, anna.schumaker@netapp.com,
linux@roeck-us.net
In-Reply-To: <4e2438a23d2edf03368950a72ec058d1d299c32e.camel@hammerspace.com>
[adding the atomic maintainers]
On Thu, Nov 01, 2018 at 12:17:31AM +0000, Trond Myklebust wrote:
> On Wed, 2018-10-31 at 23:32 +0000, Paul Burton wrote:
> > (Copying SunRPC & net maintainers.)
> >
> > Hi Guenter,
> >
> > On Wed, Oct 31, 2018 at 03:02:53PM -0700, Guenter Roeck wrote:
> > > The alternatives I can see are
> > > - Do not use cmpxchg64() outside architecture code (ie drop its use
> > > from the offending driver, and keep doing the same whenever the
> > > problem comes up again).
> > > or
> > > - Introduce something like ARCH_HAS_CMPXCHG64 and use it to
> > > determine if cmpxchg64 is supported or not.
> > >
> > > Any preference ?
> >
> > My preference would be option 1 - avoiding cmpxchg64() where
> > possible in generic code. I wouldn't be opposed to the Kconfig
> > option if there are cases where cmpxchg64() can really help
> > performance though.
> >
> > The last time I'm aware of this coming up the affected driver was
> > modified to avoid cmpxchg64() [1].
> >
> > In this particular case I have no idea why
> > net/sunrpc/auth_gss/gss_krb5_seal.c is using cmpxchg64() at all.
> > It's essentially reinventing atomic64_fetch_inc() which is already
> > provided everywhere via CONFIG_GENERIC_ATOMIC64 & the spinlock
> > approach. At least for atomic64_* functions the assumption that all
> > access will be performed using those same functions seems somewhat
> > reasonable.
> >
> > So how does the below look? Trond?
>
> My one question (and the reason why I went with cmpxchg() in the first
> place) would be about the overflow behaviour for atomic_fetch_inc() and
> friends. I believe those functions should be OK on x86, so that when we
> overflow the counter, it behaves like an unsigned value and wraps back
> around. Is that the case for all architectures?
>
> i.e. are atomic_t/atomic64_t always guaranteed to behave like u32/u64
> on increment?
>
> I could not find any documentation that explicitly stated that they
> should.
Peter, Will, I understand that the atomic_t/atomic64_t ops are required
to wrap per 2's-complement. IIUC the refcount code relies on this.
Can you confirm?
Thanks,
Mark.
> Cheers
> Trond
>
> > Thanks,
> > Paul
> >
> > [1] https://patchwork.ozlabs.org/cover/891284/
> >
> > ---
> > diff --git a/include/linux/sunrpc/gss_krb5.h
> > b/include/linux/sunrpc/gss_krb5.h
> > index 131424cefc6a..02c0412e368c 100644
> > --- a/include/linux/sunrpc/gss_krb5.h
> > +++ b/include/linux/sunrpc/gss_krb5.h
> > @@ -107,8 +107,8 @@ struct krb5_ctx {
> > u8 Ksess[GSS_KRB5_MAX_KEYLEN]; /*
> > session key */
> > u8 cksum[GSS_KRB5_MAX_KEYLEN];
> > s32 endtime;
> > - u32 seq_send;
> > - u64 seq_send64;
> > + atomic_t seq_send;
> > + atomic64_t seq_send64;
> > struct xdr_netobj mech_used;
> > u8 initiator_sign[GSS_KRB5_MAX_KEYLEN];
> > u8 acceptor_sign[GSS_KRB5_MAX_KEYLEN];
> > @@ -118,9 +118,6 @@ struct krb5_ctx {
> > u8 acceptor_integ[GSS_KRB5_MAX_KEYLEN];
> > };
> >
> > -extern u32 gss_seq_send_fetch_and_inc(struct krb5_ctx *ctx);
> > -extern u64 gss_seq_send64_fetch_and_inc(struct krb5_ctx *ctx);
> > -
> > /* The length of the Kerberos GSS token header */
> > #define GSS_KRB5_TOK_HDR_LEN (16)
> >
> > diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c
> > b/net/sunrpc/auth_gss/gss_krb5_mech.c
> > index 7f0424dfa8f6..eab71fc7af3e 100644
> > --- a/net/sunrpc/auth_gss/gss_krb5_mech.c
> > +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
> > @@ -274,6 +274,7 @@ get_key(const void *p, const void *end,
> > static int
> > gss_import_v1_context(const void *p, const void *end, struct
> > krb5_ctx *ctx)
> > {
> > + u32 seq_send;
> > int tmp;
> >
> > p = simple_get_bytes(p, end, &ctx->initiate, sizeof(ctx-
> > >initiate));
> > @@ -315,9 +316,10 @@ gss_import_v1_context(const void *p, const void
> > *end, struct krb5_ctx *ctx)
> > p = simple_get_bytes(p, end, &ctx->endtime, sizeof(ctx-
> > >endtime));
> > if (IS_ERR(p))
> > goto out_err;
> > - p = simple_get_bytes(p, end, &ctx->seq_send, sizeof(ctx-
> > >seq_send));
> > + p = simple_get_bytes(p, end, &seq_send, sizeof(seq_send));
> > if (IS_ERR(p))
> > goto out_err;
> > + atomic_set(&ctx->seq_send, seq_send);
> > p = simple_get_netobj(p, end, &ctx->mech_used);
> > if (IS_ERR(p))
> > goto out_err;
> > @@ -607,6 +609,7 @@ static int
> > gss_import_v2_context(const void *p, const void *end, struct
> > krb5_ctx *ctx,
> > gfp_t gfp_mask)
> > {
> > + u64 seq_send64;
> > int keylen;
> >
> > p = simple_get_bytes(p, end, &ctx->flags, sizeof(ctx->flags));
> > @@ -617,14 +620,15 @@ gss_import_v2_context(const void *p, const void
> > *end, struct krb5_ctx *ctx,
> > p = simple_get_bytes(p, end, &ctx->endtime, sizeof(ctx-
> > >endtime));
> > if (IS_ERR(p))
> > goto out_err;
> > - p = simple_get_bytes(p, end, &ctx->seq_send64, sizeof(ctx-
> > >seq_send64));
> > + p = simple_get_bytes(p, end, &seq_send64, sizeof(seq_send64));
> > if (IS_ERR(p))
> > goto out_err;
> > + atomic64_set(&ctx->seq_send64, seq_send64);
> > /* set seq_send for use by "older" enctypes */
> > - ctx->seq_send = ctx->seq_send64;
> > - if (ctx->seq_send64 != ctx->seq_send) {
> > - dprintk("%s: seq_send64 %lx, seq_send %x overflow?\n",
> > __func__,
> > - (unsigned long)ctx->seq_send64, ctx->seq_send);
> > + atomic_set(&ctx->seq_send, seq_send64);
> > + if (seq_send64 != atomic_read(&ctx->seq_send)) {
> > + dprintk("%s: seq_send64 %llx, seq_send %x overflow?\n",
> > __func__,
> > + seq_send64, atomic_read(&ctx->seq_send));
> > p = ERR_PTR(-EINVAL);
> > goto out_err;
> > }
> > diff --git a/net/sunrpc/auth_gss/gss_krb5_seal.c
> > b/net/sunrpc/auth_gss/gss_krb5_seal.c
> > index b4adeb06660b..48fe4a591b54 100644
> > --- a/net/sunrpc/auth_gss/gss_krb5_seal.c
> > +++ b/net/sunrpc/auth_gss/gss_krb5_seal.c
> > @@ -123,30 +123,6 @@ setup_token_v2(struct krb5_ctx *ctx, struct
> > xdr_netobj *token)
> > return krb5_hdr;
> > }
> >
> > -u32
> > -gss_seq_send_fetch_and_inc(struct krb5_ctx *ctx)
> > -{
> > - u32 old, seq_send = READ_ONCE(ctx->seq_send);
> > -
> > - do {
> > - old = seq_send;
> > - seq_send = cmpxchg(&ctx->seq_send, old, old + 1);
> > - } while (old != seq_send);
> > - return seq_send;
> > -}
> > -
> > -u64
> > -gss_seq_send64_fetch_and_inc(struct krb5_ctx *ctx)
> > -{
> > - u64 old, seq_send = READ_ONCE(ctx->seq_send);
> > -
> > - do {
> > - old = seq_send;
> > - seq_send = cmpxchg64(&ctx->seq_send64, old, old + 1);
> > - } while (old != seq_send);
> > - return seq_send;
> > -}
> > -
> > static u32
> > gss_get_mic_v1(struct krb5_ctx *ctx, struct xdr_buf *text,
> > struct xdr_netobj *token)
> > @@ -177,7 +153,7 @@ gss_get_mic_v1(struct krb5_ctx *ctx, struct
> > xdr_buf *text,
> >
> > memcpy(ptr + GSS_KRB5_TOK_HDR_LEN, md5cksum.data,
> > md5cksum.len);
> >
> > - seq_send = gss_seq_send_fetch_and_inc(ctx);
> > + seq_send = atomic_fetch_inc(&ctx->seq_send);
> >
> > if (krb5_make_seq_num(ctx, ctx->seq, ctx->initiate ? 0 : 0xff,
> > seq_send, ptr + GSS_KRB5_TOK_HDR_LEN, ptr
> > + 8))
> > @@ -205,7 +181,7 @@ gss_get_mic_v2(struct krb5_ctx *ctx, struct
> > xdr_buf *text,
> >
> > /* Set up the sequence number. Now 64-bits in clear
> > * text and w/o direction indicator */
> > - seq_send_be64 = cpu_to_be64(gss_seq_send64_fetch_and_inc(ctx));
> > + seq_send_be64 = cpu_to_be64(atomic64_fetch_inc(&ctx-
> > >seq_send64));
> > memcpy(krb5_hdr + 8, (char *) &seq_send_be64, 8);
> >
> > if (ctx->initiate) {
> > diff --git a/net/sunrpc/auth_gss/gss_krb5_wrap.c
> > b/net/sunrpc/auth_gss/gss_krb5_wrap.c
> > index 962fa84e6db1..5cdde6cb703a 100644
> > --- a/net/sunrpc/auth_gss/gss_krb5_wrap.c
> > +++ b/net/sunrpc/auth_gss/gss_krb5_wrap.c
> > @@ -228,7 +228,7 @@ gss_wrap_kerberos_v1(struct krb5_ctx *kctx, int
> > offset,
> >
> > memcpy(ptr + GSS_KRB5_TOK_HDR_LEN, md5cksum.data,
> > md5cksum.len);
> >
> > - seq_send = gss_seq_send_fetch_and_inc(kctx);
> > + seq_send = atomic_fetch_inc(&kctx->seq_send);
> >
> > /* XXX would probably be more efficient to compute checksum
> > * and encrypt at the same time: */
> > @@ -475,7 +475,7 @@ gss_wrap_kerberos_v2(struct krb5_ctx *kctx, u32
> > offset,
> > *be16ptr++ = 0;
> >
> > be64ptr = (__be64 *)be16ptr;
> > - *be64ptr = cpu_to_be64(gss_seq_send64_fetch_and_inc(kctx));
> > + *be64ptr = cpu_to_be64(atomic64_fetch_inc(&kctx->seq_send64));
> >
> > err = (*kctx->gk5e->encrypt_v2)(kctx, offset, buf, pages);
> > if (err)
> --
> Trond Myklebust
> CTO, Hammerspace Inc
> 4300 El Camino Real, Suite 105
> Los Altos, CA 94022
> www.hammer.space
>
>
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Peter Zijlstra @ 2018-11-01 14:59 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-mips@linux-mips.org, linux-nfs@vger.kernel.org,
arnd@arndb.de, jhogan@kernel.org, Boqun Feng, jlayton@kernel.org,
linux-kernel@vger.kernel.org, ralf@linux-mips.org,
davem@davemloft.net, bfields@fieldses.org, paul.burton@mips.com,
netdev@vger.kernel.org, paulus@samba.org, Trond Myklebust,
Will Deacon, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, anna.schumaker@netapp.com,
linux@roeck-us.net
In-Reply-To: <20181101131846.biyilr2msonljmij@lakrids.cambridge.arm.com>
On Thu, Nov 01, 2018 at 01:18:46PM +0000, Mark Rutland wrote:
> > My one question (and the reason why I went with cmpxchg() in the first
> > place) would be about the overflow behaviour for atomic_fetch_inc() and
> > friends. I believe those functions should be OK on x86, so that when we
> > overflow the counter, it behaves like an unsigned value and wraps back
> > around. Is that the case for all architectures?
> >
> > i.e. are atomic_t/atomic64_t always guaranteed to behave like u32/u64
> > on increment?
> >
> > I could not find any documentation that explicitly stated that they
> > should.
>
> Peter, Will, I understand that the atomic_t/atomic64_t ops are required
> to wrap per 2's-complement. IIUC the refcount code relies on this.
>
> Can you confirm?
There is quite a bit of core code that hard assumes 2s-complement. Not
only for atomics but for any signed integer type. Also see the kernel
using -fno-strict-overflow which implies -fwrapv, which defines signed
overflow to behave like 2s-complement (and rids us of that particular
UB).
^ permalink raw reply
* Re: [PATCH 01/21] of: Add cpu node iterator for_each_of_cpu_node()
From: Segher Boessenkool @ 2018-11-01 15:12 UTC (permalink / raw)
To: Michael Ellerman
Cc: Rob Herring, devicetree, Frank Rowand, Linux Kernel Mailing List,
Tyrel Datwyler, linuxppc-dev
In-Reply-To: <87tvl1dq7q.fsf@concordia.ellerman.id.au>
On Thu, Nov 01, 2018 at 09:52:57PM +1100, Michael Ellerman wrote:
> Rob Herring <robh@kernel.org> writes:
> > Yes, I was aware at least older powerpc DTs don't use 'cpu' for node names.
>
> Actually newer ones too, see below :)
Good, because that is required by the Open Firmware standard (the PowerPC
binding, to be exact):
http://www.openbios.org/data/docs/ppc-2_1.ps
(see 5.1.4, "name").
Segher
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Trond Myklebust @ 2018-11-01 15:22 UTC (permalink / raw)
To: mark.rutland@arm.com, peterz@infradead.org
Cc: linux-mips@linux-mips.org, linux-nfs@vger.kernel.org,
arnd@arndb.de, will.deacon@arm.com, boqun.feng@gmail.com,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, davem@davemloft.net, bfields@fieldses.org,
paul.burton@mips.com, netdev@vger.kernel.org, paulus@samba.org,
jhogan@kernel.org, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, anna.schumaker@netapp.com,
linux@roeck-us.net
In-Reply-To: <20181101145926.GE3178@hirez.programming.kicks-ass.net>
On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote:
> On Thu, Nov 01, 2018 at 01:18:46PM +0000, Mark Rutland wrote:
> > > My one question (and the reason why I went with cmpxchg() in the
> > > first
> > > place) would be about the overflow behaviour for
> > > atomic_fetch_inc() and
> > > friends. I believe those functions should be OK on x86, so that
> > > when we
> > > overflow the counter, it behaves like an unsigned value and wraps
> > > back
> > > around. Is that the case for all architectures?
> > >
> > > i.e. are atomic_t/atomic64_t always guaranteed to behave like
> > > u32/u64
> > > on increment?
> > >
> > > I could not find any documentation that explicitly stated that
> > > they
> > > should.
> >
> > Peter, Will, I understand that the atomic_t/atomic64_t ops are
> > required
> > to wrap per 2's-complement. IIUC the refcount code relies on this.
> >
> > Can you confirm?
>
> There is quite a bit of core code that hard assumes 2s-complement.
> Not
> only for atomics but for any signed integer type. Also see the kernel
> using -fno-strict-overflow which implies -fwrapv, which defines
> signed
> overflow to behave like 2s-complement (and rids us of that particular
> UB).
Fair enough, but there have also been bugfixes to explicitly fix unsafe
C standards assumptions for signed integers. See, for instance commit
5a581b367b5d "jiffies: Avoid undefined behavior from signed overflow"
from Paul McKenney.
Anyhow, if the atomic maintainers are willing to stand up and state for
the record that the atomic counters are guaranteed to wrap modulo 2^n
just like unsigned integers, then I'm happy to take Paul's patch.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Guenter Roeck @ 2018-11-01 15:28 UTC (permalink / raw)
To: Trond Myklebust
Cc: linux-mips@linux-mips.org, linux-nfs@vger.kernel.org,
arnd@arndb.de, jhogan@kernel.org, jlayton@kernel.org,
linux-kernel@vger.kernel.org, ralf@linux-mips.org,
davem@davemloft.net, bfields@fieldses.org, paul.burton@mips.com,
paulus@samba.org, netdev@vger.kernel.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
anna.schumaker@netapp.com
In-Reply-To: <d7fe095d8d1f848b5742a5b3e8cce9f89e0c1c8d.camel@hammerspace.com>
On Thu, Nov 01, 2018 at 06:30:08AM +0000, Trond Myklebust wrote:
[ ... ]
> >
> > For my part I agree that this would be a much better solution. The
> > argument
> > that it is not always absolutely guaranteed that atomics don't wrap
> > doesn't
> > really hold for me because it looks like they all do. On top of that,
> > there
> > is an explicit atomic_dec_if_positive() and
> > atomic_fetch_add_unless(),
> > which to me strongly suggests that they _are_ supposed to wrap.
> > Given the cost of adding a comparison to each atomic operation to
> > prevent it from wrapping, anything else would not really make sense
> > to me.
>
> That's a hypothesis, not a proven fact. There are architectures out
> there that do not wrap signed integers, hence my question.
>
If what you say is correct, the kernel is in big trouble on those architectures.
atomic_inc_return() is used all over the place in the kernel with the assumption
that each returned value differs from the previous value (ie the value is used
as cookie, session ID, or for similar purposes).
Guenter
^ permalink raw reply
* Re: [PATCH 01/21] of: Add cpu node iterator for_each_of_cpu_node()
From: Rob Herring @ 2018-11-01 15:57 UTC (permalink / raw)
To: segher
Cc: devicetree, Frank Rowand, linux-kernel@vger.kernel.org,
Tyrel Datwyler, linuxppc-dev
In-Reply-To: <20181101151201.GJ5994@gate.crashing.org>
On Thu, Nov 1, 2018 at 10:12 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Thu, Nov 01, 2018 at 09:52:57PM +1100, Michael Ellerman wrote:
> > Rob Herring <robh@kernel.org> writes:
> > > Yes, I was aware at least older powerpc DTs don't use 'cpu' for node names.
> >
> > Actually newer ones too, see below :)
>
> Good, because that is required by the Open Firmware standard (the PowerPC
> binding, to be exact):
>
> http://www.openbios.org/data/docs/ppc-2_1.ps
>
> (see 5.1.4, "name").
Yes. I should say I only expect systems following ePAPR (3.7) or DT
Spec will use 'cpu' node names. Those specs also require 'device_type'
which is supposed to indicate what OF methods are available for a node
which doesn't exist on FDT.
Rob
^ permalink raw reply
* Re: [PATCH] raid6/ppc: Fix build for clang
From: Nick Desaulniers @ 2018-11-01 16:05 UTC (permalink / raw)
To: mpe; +Cc: Kees Cook, Arnd Bergmann, jji, LKML, joel, linuxppc-dev
In-Reply-To: <87y3ad76pg.fsf@concordia.ellerman.id.au>
On Wed, Oct 31, 2018 at 9:38 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Nick Desaulniers <ndesaulniers@google.com> writes:
> > On Tue, Oct 30, 2018 at 8:28 PM Joel Stanley <joel@jms.id.au> wrote:
> >>
> >> We cannot build these files with clang as it does not allow altivec
> >> instructions in assembly when -msoft-float is passed.
> >>
> >> Jinsong Ji <jji@us.ibm.com> wrote:
> >> > We currently disable Altivec/VSX support when enabling soft-float. So
> >> > any usage of vector builtins will break.
> >> >
> >> > Enable Altivec/VSX with soft-float may need quite some clean up work, so
> >> > I guess this is currently a limitation.
> >> >
> >> > Removing -msoft-float will make it work (and we are lucky that no
> >> > floating point instructions will be generated as well).
> >>
> >> This is a workaround until the issue is resolved in clang.
> >>
> >> Link: https://bugs.llvm.org/show_bug.cgi?id=31177
> >> Link: https://github.com/ClangBuiltLinux/linux/issues/239
> >> Signed-off-by: Joel Stanley <joel@jms.id.au>
> >
> > Hopefully we can have this fixed up soon. I'll try to see who works
> > on Clang+PPC here and see if they can help move that bug along. Thanks
> > for the patch!
> >
> >> ---
> >> lib/raid6/Makefile | 15 +++++++++++++++
> >> 1 file changed, 15 insertions(+)
> >>
> >> diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> >> index 2f8b61dfd9b0..3a844e6fd01c 100644
> >> --- a/lib/raid6/Makefile
> >> +++ b/lib/raid6/Makefile
> >> @@ -18,6 +18,21 @@ quiet_cmd_unroll = UNROLL $@
> >>
> >> ifeq ($(CONFIG_ALTIVEC),y)
> >> altivec_flags := -maltivec $(call cc-option,-mabi=altivec)
> >> +
> >> +ifdef CONFIG_CC_IS_CLANG
> >
> > Note that the top level makefile detects clang via:
> >
> > ifeq ($(cc-name),clang)
> >
> > Does that not work here? I'd prefer to keep compiler detection in
> > Makefiles consistent, if it works?
>
> cc-name is being removed in favor of CONFIG_CC_IS_CLANG:
>
> https://lore.kernel.org/lkml/1540905994-6073-1-git-send-email-yamada.masahiro@socionext.com/
>
> cheers
Cool, thanks for the link!
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Peter Zijlstra @ 2018-11-01 16:32 UTC (permalink / raw)
To: Trond Myklebust
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
will.deacon@arm.com, bfields@fieldses.org, paulus@samba.org,
jhogan@kernel.org, aryabinin, Paul McKenney, linux@roeck-us.net,
arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <f38e272f7a96e983549e4281aa9fd02833a4277a.camel@hammerspace.com>
On Thu, Nov 01, 2018 at 03:22:15PM +0000, Trond Myklebust wrote:
> On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote:
> > On Thu, Nov 01, 2018 at 01:18:46PM +0000, Mark Rutland wrote:
> > > > My one question (and the reason why I went with cmpxchg() in the
> > > > first place) would be about the overflow behaviour for
> > > > atomic_fetch_inc() and friends. I believe those functions should
> > > > be OK on x86, so that when we overflow the counter, it behaves
> > > > like an unsigned value and wraps back around. Is that the case
> > > > for all architectures?
> > > >
> > > > i.e. are atomic_t/atomic64_t always guaranteed to behave like
> > > > u32/u64 on increment?
> > > >
> > > > I could not find any documentation that explicitly stated that
> > > > they should.
> > >
> > > Peter, Will, I understand that the atomic_t/atomic64_t ops are
> > > required to wrap per 2's-complement. IIUC the refcount code relies
> > > on this.
> > >
> > > Can you confirm?
> >
> > There is quite a bit of core code that hard assumes 2s-complement.
> > Not only for atomics but for any signed integer type. Also see the
> > kernel using -fno-strict-overflow which implies -fwrapv, which
> > defines signed overflow to behave like 2s-complement (and rids us of
> > that particular UB).
>
> Fair enough, but there have also been bugfixes to explicitly fix unsafe
> C standards assumptions for signed integers. See, for instance commit
> 5a581b367b5d "jiffies: Avoid undefined behavior from signed overflow"
> from Paul McKenney.
Yes, I feel Paul has been to too many C/C++ committee meetings and got
properly paranoid. Which isn't always a bad thing :-)
But for us using -fno-strict-overflow which actually defines signed
overflow, I myself am really not worried. I'm also not sure if KASAN has
been taught about this, or if it will still (incorrectly) warn about UB
for signed types.
> Anyhow, if the atomic maintainers are willing to stand up and state for
> the record that the atomic counters are guaranteed to wrap modulo 2^n
> just like unsigned integers, then I'm happy to take Paul's patch.
I myself am certainly relying on it.
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Eric Dumazet @ 2018-11-01 16:59 UTC (permalink / raw)
To: Peter Zijlstra, Trond Myklebust
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
will.deacon@arm.com, bfields@fieldses.org, paulus@samba.org,
jhogan@kernel.org, aryabinin, Paul McKenney, linux@roeck-us.net,
arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101163212.GF3159@hirez.programming.kicks-ass.net>
On 11/01/2018 09:32 AM, Peter Zijlstra wrote:
>> Anyhow, if the atomic maintainers are willing to stand up and state for
>> the record that the atomic counters are guaranteed to wrap modulo 2^n
>> just like unsigned integers, then I'm happy to take Paul's patch.
>
> I myself am certainly relying on it.
Could we get uatomic_t support maybe ?
This reminds me of this sooooo silly patch :/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Peter Zijlstra @ 2018-11-01 17:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
will.deacon@arm.com, bfields@fieldses.org, paulus@samba.org,
Trond Myklebust, jhogan@kernel.org, aryabinin, Paul McKenney,
linux@roeck-us.net, arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <b0160f4b-b996-b0ee-405a-3d5f1866272e@gmail.com>
On Thu, Nov 01, 2018 at 09:59:38AM -0700, Eric Dumazet wrote:
> On 11/01/2018 09:32 AM, Peter Zijlstra wrote:
>
> >> Anyhow, if the atomic maintainers are willing to stand up and state for
> >> the record that the atomic counters are guaranteed to wrap modulo 2^n
> >> just like unsigned integers, then I'm happy to take Paul's patch.
> >
> > I myself am certainly relying on it.
>
> Could we get uatomic_t support maybe ?
Whatever for; it'd be the exact identical same functions as for
atomic_t, except for a giant amount of code duplication to deal with the
new type.
That is; today we merged a bunch of scripts that generates most of
atomic*_t, so we could probably script uatomic*_t wrappers with minimal
effort, but it would add several thousand lines of code to each compile
for absolutely no reason what so ever.
> This reminds me of this sooooo silly patch :/
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7
Yes, that's stupid. UBSAN is just wrong there.
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Peter Zijlstra @ 2018-11-01 17:18 UTC (permalink / raw)
To: Paul E. McKenney
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
will.deacon@arm.com, bfields@fieldses.org, paulus@samba.org,
Trond Myklebust, jhogan@kernel.org, aryabinin, linux@roeck-us.net,
arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101170146.GQ4170@linux.ibm.com>
On Thu, Nov 01, 2018 at 10:01:46AM -0700, Paul E. McKenney wrote:
> On Thu, Nov 01, 2018 at 05:32:12PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 01, 2018 at 03:22:15PM +0000, Trond Myklebust wrote:
> > > On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote:
> > > > On Thu, Nov 01, 2018 at 01:18:46PM +0000, Mark Rutland wrote:
> >
> > > > > > My one question (and the reason why I went with cmpxchg() in the
> > > > > > first place) would be about the overflow behaviour for
> > > > > > atomic_fetch_inc() and friends. I believe those functions should
> > > > > > be OK on x86, so that when we overflow the counter, it behaves
> > > > > > like an unsigned value and wraps back around. Is that the case
> > > > > > for all architectures?
> > > > > >
> > > > > > i.e. are atomic_t/atomic64_t always guaranteed to behave like
> > > > > > u32/u64 on increment?
> > > > > >
> > > > > > I could not find any documentation that explicitly stated that
> > > > > > they should.
> > > > >
> > > > > Peter, Will, I understand that the atomic_t/atomic64_t ops are
> > > > > required to wrap per 2's-complement. IIUC the refcount code relies
> > > > > on this.
> > > > >
> > > > > Can you confirm?
> > > >
> > > > There is quite a bit of core code that hard assumes 2s-complement.
> > > > Not only for atomics but for any signed integer type. Also see the
> > > > kernel using -fno-strict-overflow which implies -fwrapv, which
> > > > defines signed overflow to behave like 2s-complement (and rids us of
> > > > that particular UB).
> > >
> > > Fair enough, but there have also been bugfixes to explicitly fix unsafe
> > > C standards assumptions for signed integers. See, for instance commit
> > > 5a581b367b5d "jiffies: Avoid undefined behavior from signed overflow"
> > > from Paul McKenney.
> >
> > Yes, I feel Paul has been to too many C/C++ committee meetings and got
> > properly paranoid. Which isn't always a bad thing :-)
>
> Even the C standard defines 2s complement for atomics.
Ooh good to know.
> Just not for
> normal arithmetic, where yes, signed overflow is UB. And yes, I do
> know about -fwrapv, but I would like to avoid at least some copy-pasta
> UB from my kernel code to who knows what user-mode environment. :-/
>
> At least where it is reasonably easy to do so.
Fair enough I suppose; I just always make sure to include the same
-fknobs for the userspace thing when I lift code.
> And there is a push to define C++ signed arithmetic as 2s complement,
> but there are still 1s complement systems with C compilers. Just not
> C++ compilers. Legacy...
*groan*; how about those ancient hardwares keep using ancient compilers
and we all move on to the 70s :-)
> > But for us using -fno-strict-overflow which actually defines signed
> > overflow, I myself am really not worried. I'm also not sure if KASAN has
> > been taught about this, or if it will still (incorrectly) warn about UB
> > for signed types.
>
> UBSAN gave me a signed-overflow warning a few days ago. Which I have
> fixed, even though 2s complement did the right thing. I am also taking
> advantage of the change to use better naming.
Oh too many *SANs I suppose; and yes, if you can make the code better,
why not.
> > > Anyhow, if the atomic maintainers are willing to stand up and state for
> > > the record that the atomic counters are guaranteed to wrap modulo 2^n
> > > just like unsigned integers, then I'm happy to take Paul's patch.
> >
> > I myself am certainly relying on it.
>
> Color me confused. My 5a581b367b5d is from 2013. Or is "Paul" instead
> intended to mean Paul Mackerras, who happens to be on CC?
Paul Burton I think, on a part of the thread before we joined :-)
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Peter Zijlstra @ 2018-11-01 17:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
will.deacon@arm.com, bfields@fieldses.org, paulus@samba.org,
Trond Myklebust, jhogan@kernel.org, aryabinin, Paul McKenney,
linux@roeck-us.net, arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101171432.GH3178@hirez.programming.kicks-ass.net>
On Thu, Nov 01, 2018 at 06:14:32PM +0100, Peter Zijlstra wrote:
> > This reminds me of this sooooo silly patch :/
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7
You'd probably want to write it like so; +- some ordering stuff, that
code didn't look like it really needs the memory barriers implied by
these, but I didn't look too hard.
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index c0a9d26c06ce..11deb1d7e96b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -485,16 +485,10 @@ u32 ip_idents_reserve(u32 hash, int segs)
u32 now = (u32)jiffies;
u32 new, delta = 0;
- if (old != now && cmpxchg(p_tstamp, old, now) == old)
+ if (old != now && try_cmpxchg(p_tstamp, &old, now))
delta = prandom_u32_max(now - old);
- /* Do not use atomic_add_return() as it makes UBSAN unhappy */
- do {
- old = (u32)atomic_read(p_id);
- new = old + delta + segs;
- } while (atomic_cmpxchg(p_id, old, new) != old);
-
- return new - segs;
+ return atomic_fetch_add(segs + delta, p_id) + delta;
}
EXPORT_SYMBOL(ip_idents_reserve);
^ permalink raw reply related
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Paul Burton @ 2018-11-01 17:54 UTC (permalink / raw)
To: Trond Myklebust
Cc: linux-mips@linux-mips.org, linux-nfs@vger.kernel.org,
arnd@arndb.de, jhogan@kernel.org, jlayton@kernel.org,
linux-kernel@vger.kernel.org, ralf@linux-mips.org,
davem@davemloft.net, bfields@fieldses.org, paulus@samba.org,
netdev@vger.kernel.org, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, anna.schumaker@netapp.com,
linux@roeck-us.net
In-Reply-To: <4e2438a23d2edf03368950a72ec058d1d299c32e.camel@hammerspace.com>
Hi Trond,
On Thu, Nov 01, 2018 at 12:17:31AM +0000, Trond Myklebust wrote:
> On Wed, 2018-10-31 at 23:32 +0000, Paul Burton wrote:
> > In this particular case I have no idea why
> > net/sunrpc/auth_gss/gss_krb5_seal.c is using cmpxchg64() at all. It's
> > essentially reinventing atomic64_fetch_inc() which is already
> > provided
> > everywhere via CONFIG_GENERIC_ATOMIC64 & the spinlock approach. At
> > least
> > for atomic64_* functions the assumption that all access will be
> > performed using those same functions seems somewhat reasonable.
> >
> > So how does the below look? Trond?
>
> My one question (and the reason why I went with cmpxchg() in the first
> place) would be about the overflow behaviour for atomic_fetch_inc() and
> friends. I believe those functions should be OK on x86, so that when we
> overflow the counter, it behaves like an unsigned value and wraps back
> around. Is that the case for all architectures?
>
> i.e. are atomic_t/atomic64_t always guaranteed to behave like u32/u64
> on increment?
>
> I could not find any documentation that explicitly stated that they
> should.
Based on other replies it seems like it's at least implicitly assumed by
other code, even if not explicitly stated.
From a MIPS perspective where atomics are implemented using load-linked
& store-conditional instructions the actual addition will be performed
using the same addu instruction that a plain integer addition would
generate (regardless of signedness), so there'll be absolutely no
difference in arithmetic between your gss_seq_send64_fetch_and_inc()
function and atomic64_fetch_inc(). I'd expect the same to be true for
other architectures with load-linked & store-conditional style atomics.
In any case, for the benefit of anyone interested who I didn't copy on
the patch submission, here it is:
https://lore.kernel.org/lkml/20181101175109.8621-1-paul.burton@mips.com/
Thanks,
Paul
^ permalink raw reply
* Re: [PATCH 13/36] dt-bindings: arm: Convert PMU binding to json-schema
From: Rob Herring @ 2018-11-01 19:32 UTC (permalink / raw)
To: Will Deacon, Thomas Petazzoni
Cc: Mark Rutland, devicetree, Kumar Gala, Grant Likely, Arnd Bergmann,
Tom Rini, Frank Rowand, Linus Walleij, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Bjorn Andersson, Mark Brown,
Geert Uytterhoeven, Jonathan Cameron, Olof Johansson,
linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20181009115713.GE6248@arm.com>
On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote:
>
> Hi Rob,
>
> On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote:
> > Convert ARM PMU binding to DT schema format using json-schema.
> >
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > Documentation/devicetree/bindings/arm/pmu.txt | 70 --------------
> > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++
> > 2 files changed, 96 insertions(+), 70 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml
>
> [...]
>
> > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
> > - interrupt (PPI) then 1 interrupt should be specified.
>
> [...]
>
> > + interrupts:
> > + oneOf:
> > + - maxItems: 1
> > + - minItems: 2
> > + maxItems: 8
> > + description: 1 interrupt per core.
> > +
> > + interrupts-extended:
> > + $ref: '#/properties/interrupts'
>
> This seems like a semantic different between the two representations, or am
> I missing something here? Specifically, both the introduction of
> interrupts-extended and also dropping any mention of using a single per-cpu
> interrupt (the single combined case is no longer support by Linux; not sure
> if you want to keep it in the binding).
In regards to no support for the single combined interrupt, it looks
like Marvell Armada SoCs at least (armada-375 is what I'm looking at)
have only a single interrupt. Though the interrupt gets routed to MPIC
which then has a GIC PPI. So it isn't supported or happens to work
still since it is a PPI?
Rob
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Paul E. McKenney @ 2018-11-01 17:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
will.deacon@arm.com, bfields@fieldses.org, paulus@samba.org,
Trond Myklebust, jhogan@kernel.org, aryabinin, linux@roeck-us.net,
arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101163212.GF3159@hirez.programming.kicks-ass.net>
On Thu, Nov 01, 2018 at 05:32:12PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 01, 2018 at 03:22:15PM +0000, Trond Myklebust wrote:
> > On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 01, 2018 at 01:18:46PM +0000, Mark Rutland wrote:
>
> > > > > My one question (and the reason why I went with cmpxchg() in the
> > > > > first place) would be about the overflow behaviour for
> > > > > atomic_fetch_inc() and friends. I believe those functions should
> > > > > be OK on x86, so that when we overflow the counter, it behaves
> > > > > like an unsigned value and wraps back around. Is that the case
> > > > > for all architectures?
> > > > >
> > > > > i.e. are atomic_t/atomic64_t always guaranteed to behave like
> > > > > u32/u64 on increment?
> > > > >
> > > > > I could not find any documentation that explicitly stated that
> > > > > they should.
> > > >
> > > > Peter, Will, I understand that the atomic_t/atomic64_t ops are
> > > > required to wrap per 2's-complement. IIUC the refcount code relies
> > > > on this.
> > > >
> > > > Can you confirm?
> > >
> > > There is quite a bit of core code that hard assumes 2s-complement.
> > > Not only for atomics but for any signed integer type. Also see the
> > > kernel using -fno-strict-overflow which implies -fwrapv, which
> > > defines signed overflow to behave like 2s-complement (and rids us of
> > > that particular UB).
> >
> > Fair enough, but there have also been bugfixes to explicitly fix unsafe
> > C standards assumptions for signed integers. See, for instance commit
> > 5a581b367b5d "jiffies: Avoid undefined behavior from signed overflow"
> > from Paul McKenney.
>
> Yes, I feel Paul has been to too many C/C++ committee meetings and got
> properly paranoid. Which isn't always a bad thing :-)
Even the C standard defines 2s complement for atomics. Just not for
normal arithmetic, where yes, signed overflow is UB. And yes, I do
know about -fwrapv, but I would like to avoid at least some copy-pasta
UB from my kernel code to who knows what user-mode environment. :-/
At least where it is reasonably easy to do so.
And there is a push to define C++ signed arithmetic as 2s complement,
but there are still 1s complement systems with C compilers. Just not
C++ compilers. Legacy...
> But for us using -fno-strict-overflow which actually defines signed
> overflow, I myself am really not worried. I'm also not sure if KASAN has
> been taught about this, or if it will still (incorrectly) warn about UB
> for signed types.
UBSAN gave me a signed-overflow warning a few days ago. Which I have
fixed, even though 2s complement did the right thing. I am also taking
advantage of the change to use better naming.
> > Anyhow, if the atomic maintainers are willing to stand up and state for
> > the record that the atomic counters are guaranteed to wrap modulo 2^n
> > just like unsigned integers, then I'm happy to take Paul's patch.
>
> I myself am certainly relying on it.
Color me confused. My 5a581b367b5d is from 2013. Or is "Paul" instead
intended to mean Paul Mackerras, who happens to be on CC?
Thanx, Paul
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Paul E. McKenney @ 2018-11-01 17:34 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
will.deacon@arm.com, bfields@fieldses.org, paulus@samba.org,
Trond Myklebust, jhogan@kernel.org, aryabinin, linux@roeck-us.net,
arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101171846.GI3178@hirez.programming.kicks-ass.net>
On Thu, Nov 01, 2018 at 06:18:46PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 01, 2018 at 10:01:46AM -0700, Paul E. McKenney wrote:
> > On Thu, Nov 01, 2018 at 05:32:12PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 01, 2018 at 03:22:15PM +0000, Trond Myklebust wrote:
> > > > On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote:
> > > > > On Thu, Nov 01, 2018 at 01:18:46PM +0000, Mark Rutland wrote:
> > >
> > > > > > > My one question (and the reason why I went with cmpxchg() in the
> > > > > > > first place) would be about the overflow behaviour for
> > > > > > > atomic_fetch_inc() and friends. I believe those functions should
> > > > > > > be OK on x86, so that when we overflow the counter, it behaves
> > > > > > > like an unsigned value and wraps back around. Is that the case
> > > > > > > for all architectures?
> > > > > > >
> > > > > > > i.e. are atomic_t/atomic64_t always guaranteed to behave like
> > > > > > > u32/u64 on increment?
> > > > > > >
> > > > > > > I could not find any documentation that explicitly stated that
> > > > > > > they should.
> > > > > >
> > > > > > Peter, Will, I understand that the atomic_t/atomic64_t ops are
> > > > > > required to wrap per 2's-complement. IIUC the refcount code relies
> > > > > > on this.
> > > > > >
> > > > > > Can you confirm?
> > > > >
> > > > > There is quite a bit of core code that hard assumes 2s-complement.
> > > > > Not only for atomics but for any signed integer type. Also see the
> > > > > kernel using -fno-strict-overflow which implies -fwrapv, which
> > > > > defines signed overflow to behave like 2s-complement (and rids us of
> > > > > that particular UB).
> > > >
> > > > Fair enough, but there have also been bugfixes to explicitly fix unsafe
> > > > C standards assumptions for signed integers. See, for instance commit
> > > > 5a581b367b5d "jiffies: Avoid undefined behavior from signed overflow"
> > > > from Paul McKenney.
> > >
> > > Yes, I feel Paul has been to too many C/C++ committee meetings and got
> > > properly paranoid. Which isn't always a bad thing :-)
> >
> > Even the C standard defines 2s complement for atomics.
>
> Ooh good to know.
Must be some mistake, right? ;-)
> > Just not for
> > normal arithmetic, where yes, signed overflow is UB. And yes, I do
> > know about -fwrapv, but I would like to avoid at least some copy-pasta
> > UB from my kernel code to who knows what user-mode environment. :-/
> >
> > At least where it is reasonably easy to do so.
>
> Fair enough I suppose; I just always make sure to include the same
> -fknobs for the userspace thing when I lift code.
Agreed! But when it is other people lifting the code...
> > And there is a push to define C++ signed arithmetic as 2s complement,
> > but there are still 1s complement systems with C compilers. Just not
> > C++ compilers. Legacy...
>
> *groan*; how about those ancient hardwares keep using ancient compilers
> and we all move on to the 70s :-)
Hey!!! Some of that 70s (and 60s!) 1s-complement hardware helped pay
my way through university the first time around!!! ;-)
Though where it once filled a room it is now on a single small chip.
Go figure...
> > > But for us using -fno-strict-overflow which actually defines signed
> > > overflow, I myself am really not worried. I'm also not sure if KASAN has
> > > been taught about this, or if it will still (incorrectly) warn about UB
> > > for signed types.
> >
> > UBSAN gave me a signed-overflow warning a few days ago. Which I have
> > fixed, even though 2s complement did the right thing. I am also taking
> > advantage of the change to use better naming.
>
> Oh too many *SANs I suppose; and yes, if you can make the code better,
> why not.
Yeah, when INT_MIN was confined to a single function, no problem.
But thanks to the RCU flavor consolidation, it has to be spread out a
bit more... Plus there is now INT_MAX, INT_MAX/2, ...
> > > > Anyhow, if the atomic maintainers are willing to stand up and state for
> > > > the record that the atomic counters are guaranteed to wrap modulo 2^n
> > > > just like unsigned integers, then I'm happy to take Paul's patch.
> > >
> > > I myself am certainly relying on it.
> >
> > Color me confused. My 5a581b367b5d is from 2013. Or is "Paul" instead
> > intended to mean Paul Mackerras, who happens to be on CC?
>
> Paul Burton I think, on a part of the thread before we joined :-)
Couldn't be bothered to look up the earlier part of the thread. Getting
lazy in my old age. ;-)
Thanx, Paul
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Paul E. McKenney @ 2018-11-01 17:43 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
jhogan@kernel.org, will.deacon@arm.com, bfields@fieldses.org,
paulus@samba.org, Eric Dumazet, Trond Myklebust, aryabinin,
linux@roeck-us.net, arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101171432.GH3178@hirez.programming.kicks-ass.net>
On Thu, Nov 01, 2018 at 06:14:32PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 01, 2018 at 09:59:38AM -0700, Eric Dumazet wrote:
> > On 11/01/2018 09:32 AM, Peter Zijlstra wrote:
> >
> > >> Anyhow, if the atomic maintainers are willing to stand up and state for
> > >> the record that the atomic counters are guaranteed to wrap modulo 2^n
> > >> just like unsigned integers, then I'm happy to take Paul's patch.
> > >
> > > I myself am certainly relying on it.
> >
> > Could we get uatomic_t support maybe ?
>
> Whatever for; it'd be the exact identical same functions as for
> atomic_t, except for a giant amount of code duplication to deal with the
> new type.
>
> That is; today we merged a bunch of scripts that generates most of
> atomic*_t, so we could probably script uatomic*_t wrappers with minimal
> effort, but it would add several thousand lines of code to each compile
> for absolutely no reason what so ever.
>
> > This reminds me of this sooooo silly patch :/
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7
>
> Yes, that's stupid. UBSAN is just wrong there.
It would be good for UBSAN to treat atomic operations as guaranteed
2s complement with no UB for signed integer overflow. After all, if
even the C standard is willing to do this...
Ah, but don't we disable interrupts and fall back to normal arithmetic
for UP systems? Hmmm... We do so for atomic_add_return() even on
x86, it turns out:
static __always_inline int arch_atomic_add_return(int i, atomic_t *v)
{
return i + xadd(&v->counter, i);
}
So UBSAN actually did have a point. :-(
Thanx, Paul
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Dmitry Vyukov @ 2018-11-01 17:46 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
jhogan@kernel.org, will.deacon@arm.com, bfields@fieldses.org,
paulus@samba.org, Paul E. McKenney, Trond Myklebust,
Andrey Ryabinin, linux@roeck-us.net, arnd@arndb.de,
boqun.feng@gmail.com, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, jlayton@kernel.org,
linux-kernel@vger.kernel.org, ralf@linux-mips.org,
anna.schumaker@netapp.com, paul.burton@mips.com,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
davem@davemloft.net
In-Reply-To: <20181101171846.GI3178@hirez.programming.kicks-ass.net>
On Thu, Nov 1, 2018 at 6:18 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > > > > > My one question (and the reason why I went with cmpxchg() in the
>> > > > > > first place) would be about the overflow behaviour for
>> > > > > > atomic_fetch_inc() and friends. I believe those functions should
>> > > > > > be OK on x86, so that when we overflow the counter, it behaves
>> > > > > > like an unsigned value and wraps back around. Is that the case
>> > > > > > for all architectures?
>> > > > > >
>> > > > > > i.e. are atomic_t/atomic64_t always guaranteed to behave like
>> > > > > > u32/u64 on increment?
>> > > > > >
>> > > > > > I could not find any documentation that explicitly stated that
>> > > > > > they should.
>> > > > >
>> > > > > Peter, Will, I understand that the atomic_t/atomic64_t ops are
>> > > > > required to wrap per 2's-complement. IIUC the refcount code relies
>> > > > > on this.
>> > > > >
>> > > > > Can you confirm?
>> > > >
>> > > > There is quite a bit of core code that hard assumes 2s-complement.
>> > > > Not only for atomics but for any signed integer type. Also see the
>> > > > kernel using -fno-strict-overflow which implies -fwrapv, which
>> > > > defines signed overflow to behave like 2s-complement (and rids us of
>> > > > that particular UB).
>> > >
>> > > Fair enough, but there have also been bugfixes to explicitly fix unsafe
>> > > C standards assumptions for signed integers. See, for instance commit
>> > > 5a581b367b5d "jiffies: Avoid undefined behavior from signed overflow"
>> > > from Paul McKenney.
>> >
>> > Yes, I feel Paul has been to too many C/C++ committee meetings and got
>> > properly paranoid. Which isn't always a bad thing :-)
>>
>> Even the C standard defines 2s complement for atomics.
>
> Ooh good to know.
>
>> Just not for
>> normal arithmetic, where yes, signed overflow is UB. And yes, I do
>> know about -fwrapv, but I would like to avoid at least some copy-pasta
>> UB from my kernel code to who knows what user-mode environment. :-/
>>
>> At least where it is reasonably easy to do so.
>
> Fair enough I suppose; I just always make sure to include the same
> -fknobs for the userspace thing when I lift code.
>
>> And there is a push to define C++ signed arithmetic as 2s complement,
>> but there are still 1s complement systems with C compilers. Just not
>> C++ compilers. Legacy...
>
> *groan*; how about those ancient hardwares keep using ancient compilers
> and we all move on to the 70s :-)
>
>> > But for us using -fno-strict-overflow which actually defines signed
>> > overflow, I myself am really not worried. I'm also not sure if KASAN has
>> > been taught about this, or if it will still (incorrectly) warn about UB
>> > for signed types.
>>
>> UBSAN gave me a signed-overflow warning a few days ago. Which I have
>> fixed, even though 2s complement did the right thing. I am also taking
>> advantage of the change to use better naming.
>
> Oh too many *SANs I suppose; and yes, if you can make the code better,
> why not.
If there is a warning that we don't want to see at all, then we can
disable it. It supposed to be a useful tool, rather than a thing in
itself that lives own life. We already I think removed 1 particularly
noisy warning and made another optional via a config.
But the thing with overflows is that, even if it's defined, it's not
necessary the intended behavior. For example, take allocation size
calculation done via unsigned size_t. If it overflows it does not help
if C defines result or not, it still gives a user controlled write
primitive. We've seen similar cases with timeout/deadline calculation
in kernel, we really don't want it to just wrap modulo-2, right. Some
user-space projects even test with unsigned overflow warnings or
implicit truncation warnings, which are formally legal, but frequently
bugs.
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Paul E. McKenney @ 2018-11-01 20:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
jhogan@kernel.org, will.deacon@arm.com, bfields@fieldses.org,
paulus@samba.org, Eric Dumazet, Trond Myklebust, aryabinin,
linux@roeck-us.net, arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101172739.GA3196@hirez.programming.kicks-ass.net>
On Thu, Nov 01, 2018 at 06:27:39PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 01, 2018 at 06:14:32PM +0100, Peter Zijlstra wrote:
> > > This reminds me of this sooooo silly patch :/
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7
>
> You'd probably want to write it like so; +- some ordering stuff, that
> code didn't look like it really needs the memory barriers implied by
> these, but I didn't look too hard.
The atomic_fetch_add() API would need to be propagated out to the other
architectures, correct?
Thanx, Paul
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index c0a9d26c06ce..11deb1d7e96b 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -485,16 +485,10 @@ u32 ip_idents_reserve(u32 hash, int segs)
> u32 now = (u32)jiffies;
> u32 new, delta = 0;
>
> - if (old != now && cmpxchg(p_tstamp, old, now) == old)
> + if (old != now && try_cmpxchg(p_tstamp, &old, now))
> delta = prandom_u32_max(now - old);
>
> - /* Do not use atomic_add_return() as it makes UBSAN unhappy */
> - do {
> - old = (u32)atomic_read(p_id);
> - new = old + delta + segs;
> - } while (atomic_cmpxchg(p_id, old, new) != old);
> -
> - return new - segs;
> + return atomic_fetch_add(segs + delta, p_id) + delta;
> }
> EXPORT_SYMBOL(ip_idents_reserve);
>
>
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Peter Zijlstra @ 2018-11-01 21:38 UTC (permalink / raw)
To: Paul E. McKenney
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
jhogan@kernel.org, will.deacon@arm.com, bfields@fieldses.org,
paulus@samba.org, Eric Dumazet, Trond Myklebust, aryabinin,
linux@roeck-us.net, arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101202910.GB4170@linux.ibm.com>
On Thu, Nov 01, 2018 at 01:29:10PM -0700, Paul E. McKenney wrote:
> On Thu, Nov 01, 2018 at 06:27:39PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 01, 2018 at 06:14:32PM +0100, Peter Zijlstra wrote:
> > > > This reminds me of this sooooo silly patch :/
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7
> >
> > You'd probably want to write it like so; +- some ordering stuff, that
> > code didn't look like it really needs the memory barriers implied by
> > these, but I didn't look too hard.
>
> The atomic_fetch_add() API would need to be propagated out to the other
> architectures, correct?
Like these commits I did like 2 years ago ? :-)
$ git log --oneline 6dc25876cdb1...1f51dee7ca74
6dc25876cdb1 locking/atomic, arch/xtensa: Implement atomic_fetch_{add,sub,and,or,xor}()
a8bcccaba162 locking/atomic, arch/x86: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
1af5de9af138 locking/atomic, arch/tile: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
3a1adb23a52c locking/atomic, arch/sparc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
7d9794e75237 locking/atomic, arch/sh: Implement atomic_fetch_{add,sub,and,or,xor}()
56fefbbc3f13 locking/atomic, arch/s390: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
a28cc7bbe8e3 locking/atomic, arch/powerpc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}{,_relaxed,_acquire,_release}()
e5857a6ed600 locking/atomic, arch/parisc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
f8d638e28d7c locking/atomic, arch/mn10300: Implement atomic_fetch_{add,sub,and,or,xor}()
4edac529eb62 locking/atomic, arch/mips: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
e898eb27ffd8 locking/atomic, arch/metag: Implement atomic_fetch_{add,sub,and,or,xor}()
e39d88ea3ce4 locking/atomic, arch/m68k: Implement atomic_fetch_{add,sub,and,or,xor}()
f64937052303 locking/atomic, arch/m32r: Implement atomic_fetch_{add,sub,and,or,xor}()
cc102507fac7 locking/atomic, arch/ia64: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
4be7dd393515 locking/atomic, arch/hexagon: Implement atomic_fetch_{add,sub,and,or,xor}()
0c074cbc3309 locking/atomic, arch/h8300: Implement atomic_fetch_{add,sub,and,or,xor}()
d9c730281617 locking/atomic, arch/frv: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
e87fc0ec0705 locking/atomic, arch/blackfin: Implement atomic_fetch_{add,sub,and,or,xor}()
1a6eafacd481 locking/atomic, arch/avr32: Implement atomic_fetch_{add,sub,and,or,xor}()
2efe95fe6952 locking/atomic, arch/arm64: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}() for LSE instructions
6822a84dd4e3 locking/atomic, arch/arm64: Generate LSE non-return cases using common macros
e490f9b1d3b4 locking/atomic, arch/arm64: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()
6da068c1beba locking/atomic, arch/arm: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()
fbffe892e525 locking/atomic, arch/arc: Implement atomic_fetch_{add,sub,and,andnot,or,xor}()
^ permalink raw reply
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Peter Zijlstra @ 2018-11-01 21:45 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
jhogan@kernel.org, will.deacon@arm.com, bfields@fieldses.org,
paulus@samba.org, Paul E. McKenney, Trond Myklebust,
Andrey Ryabinin, linux@roeck-us.net, arnd@arndb.de,
boqun.feng@gmail.com, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, jlayton@kernel.org,
linux-kernel@vger.kernel.org, ralf@linux-mips.org,
anna.schumaker@netapp.com, paul.burton@mips.com,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
davem@davemloft.net
In-Reply-To: <CACT4Y+aC45BtS88DXarn3A+LV2RRRsPQoSs_3_DnKjU4O3AMHQ@mail.gmail.com>
On Thu, Nov 01, 2018 at 06:46:50PM +0100, Dmitry Vyukov wrote:
> If there is a warning that we don't want to see at all, then we can
> disable it. It supposed to be a useful tool, rather than a thing in
> itself that lives own life. We already I think removed 1 particularly
> noisy warning and made another optional via a config.
> But the thing with overflows is that, even if it's defined, it's not
> necessary the intended behavior. For example, take allocation size
> calculation done via unsigned size_t. If it overflows it does not help
> if C defines result or not, it still gives a user controlled write
> primitive. We've seen similar cases with timeout/deadline calculation
> in kernel, we really don't want it to just wrap modulo-2, right. Some
> user-space projects even test with unsigned overflow warnings or
> implicit truncation warnings, which are formally legal, but frequently
> bugs.
Sure; but then don't call it UB.
If we want to have an additional integer over/underflow checker (ideally
with a gcc plugin that has explicit annotations like __wrap to make it
go away) that is fine; and it can be done on unsigned and signed.
^ permalink raw reply
* [PATCH] powerpc/mm: remove unused function prototype
From: Breno Leitao @ 2018-11-01 21:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Breno Leitao, aneesh.kumar
Commit f384796c40dc ("powerpc/mm: Add support for handling > 512TB address
in SLB miss") removed function slb_miss_bad_addr(struct pt_regs *regs), but
kept its declaration in the prototype file. This patch simply removes the
function definition.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/include/asm/asm-prototypes.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
index ec691d489656..6f201b199c02 100644
--- a/arch/powerpc/include/asm/asm-prototypes.h
+++ b/arch/powerpc/include/asm/asm-prototypes.h
@@ -61,7 +61,6 @@ void RunModeException(struct pt_regs *regs);
void single_step_exception(struct pt_regs *regs);
void program_check_exception(struct pt_regs *regs);
void alignment_exception(struct pt_regs *regs);
-void slb_miss_bad_addr(struct pt_regs *regs);
void StackOverflow(struct pt_regs *regs);
void kernel_fp_unavailable_exception(struct pt_regs *regs);
void altivec_unavailable_exception(struct pt_regs *regs);
--
2.13.2
^ permalink raw reply related
* Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
From: Paul E. McKenney @ 2018-11-01 22:26 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland@arm.com, linux-mips@linux-mips.org,
jhogan@kernel.org, will.deacon@arm.com, bfields@fieldses.org,
paulus@samba.org, Eric Dumazet, Trond Myklebust, aryabinin,
linux@roeck-us.net, arnd@arndb.de, boqun.feng@gmail.com, dvyukov,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, anna.schumaker@netapp.com,
paul.burton@mips.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20181101213834.GA3339@worktop.programming.kicks-ass.net>
On Thu, Nov 01, 2018 at 10:38:34PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 01, 2018 at 01:29:10PM -0700, Paul E. McKenney wrote:
> > On Thu, Nov 01, 2018 at 06:27:39PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 01, 2018 at 06:14:32PM +0100, Peter Zijlstra wrote:
> > > > > This reminds me of this sooooo silly patch :/
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7
> > >
> > > You'd probably want to write it like so; +- some ordering stuff, that
> > > code didn't look like it really needs the memory barriers implied by
> > > these, but I didn't look too hard.
> >
> > The atomic_fetch_add() API would need to be propagated out to the other
> > architectures, correct?
>
> Like these commits I did like 2 years ago ? :-)
Color me blind and stupid! ;-)
Thanx, Paul
> $ git log --oneline 6dc25876cdb1...1f51dee7ca74
> 6dc25876cdb1 locking/atomic, arch/xtensa: Implement atomic_fetch_{add,sub,and,or,xor}()
> a8bcccaba162 locking/atomic, arch/x86: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> 1af5de9af138 locking/atomic, arch/tile: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> 3a1adb23a52c locking/atomic, arch/sparc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> 7d9794e75237 locking/atomic, arch/sh: Implement atomic_fetch_{add,sub,and,or,xor}()
> 56fefbbc3f13 locking/atomic, arch/s390: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> a28cc7bbe8e3 locking/atomic, arch/powerpc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}{,_relaxed,_acquire,_release}()
> e5857a6ed600 locking/atomic, arch/parisc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> f8d638e28d7c locking/atomic, arch/mn10300: Implement atomic_fetch_{add,sub,and,or,xor}()
> 4edac529eb62 locking/atomic, arch/mips: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> e898eb27ffd8 locking/atomic, arch/metag: Implement atomic_fetch_{add,sub,and,or,xor}()
> e39d88ea3ce4 locking/atomic, arch/m68k: Implement atomic_fetch_{add,sub,and,or,xor}()
> f64937052303 locking/atomic, arch/m32r: Implement atomic_fetch_{add,sub,and,or,xor}()
> cc102507fac7 locking/atomic, arch/ia64: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> 4be7dd393515 locking/atomic, arch/hexagon: Implement atomic_fetch_{add,sub,and,or,xor}()
> 0c074cbc3309 locking/atomic, arch/h8300: Implement atomic_fetch_{add,sub,and,or,xor}()
> d9c730281617 locking/atomic, arch/frv: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()
> e87fc0ec0705 locking/atomic, arch/blackfin: Implement atomic_fetch_{add,sub,and,or,xor}()
> 1a6eafacd481 locking/atomic, arch/avr32: Implement atomic_fetch_{add,sub,and,or,xor}()
> 2efe95fe6952 locking/atomic, arch/arm64: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}() for LSE instructions
> 6822a84dd4e3 locking/atomic, arch/arm64: Generate LSE non-return cases using common macros
> e490f9b1d3b4 locking/atomic, arch/arm64: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()
> 6da068c1beba locking/atomic, arch/arm: Implement atomic{,64}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()
> fbffe892e525 locking/atomic, arch/arc: Implement atomic_fetch_{add,sub,and,andnot,or,xor}()
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox