Received: by 2002:ab2:6991:0:b0:1f7:f6c3:9cb1 with SMTP id v17csp640660lqo; Wed, 8 May 2024 10:09:06 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVN5erwZ9IMFY+yOLlnWF6UtBi/Z4eBBjy4ccOef3l9Ld2GMv2qkqZjV15G7piJdY9aIzhpjZd0EJjI/UbcRoBi4cR7ZIKXWV+wcGohIw== X-Google-Smtp-Source: AGHT+IEyihoOqHL94XoCCCPru1xLRbJ1EdNzQotrEZ9a1EpbbdCFEV9WHD1qSJOqEmCxquNkSFj8 X-Received: by 2002:a05:622a:5786:b0:43a:a802:2f90 with SMTP id d75a77b69052e-43dbed3a53emr37129601cf.40.1715188146393; Wed, 08 May 2024 10:09:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715188146; cv=pass; d=google.com; s=arc-20160816; b=RCaHN5gDDIz7bXvJsFeaFeYUgGjeRV75RXgOrXfCXsAQxEFJVRM8BP+VqCse+/j02X 8Opzn9PewRBbR08O9YnTnPuoYy9FkGJCWraTmgX202GbOx5iYkSVjCNHy87xL9oQMyq9 VqfXdEi0UQNA6zO4qsXCiSKr3rTiUm548lHC70SkGd5AurkdSN6cPEsUZlvm+PIx/zpP lQbWNGY57DMDcneUDrF98ahHQ2usKj+omoVuRIGQW4w4PxeEhcyDtOsITe9KguGsrjt6 00kTmXkeeTKn+a9KaFXTP9Cjf3+SAGh5erEGsDp3x01/enTwTON6B560Znv5VN2TRRGD i7Sg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=/eSbADOZ8evw9OJw2brkuoRGmrobs41mdA4C9aigUTU=; fh=JqQpMfpA5nzM974oT6uCstMroowRTLCocBfF4ib8hD0=; b=DZee/fEf1r/CzWw1xUTUP1hOgVtZ+xHTtOuPqtHdQcoaSxmQgk6DjH+AfPfMrnHG1d g1TgQuxn/dWtOlKsv3gBO5/RScqRSau60sfW1CuN0xZbVORx7jDS8CG/hW8QbBhn72eu 9Il5vEWWCbP0NiVnYIvKVL2NGKSR9Co7lDBQm7BmzQtDRnolVMwUtvIB4YwQ7LseXcU4 6tk7j27AKcKcfDwYPnBSUZU7zeWkdamMJnFEYEVvmAYXdY77v7n+OttUNYPyYBRmwEC9 cgqAtyCrZlrL1wyLLJwrwDtyyudtc0PDS0v9E4nTDgSipnN/31qFLbOTgfCI+VCOU25B XftA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="M/97oIyG"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-173599-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-173599-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id ea15-20020a05622a5b0f00b0043b08aae9b8si13052852qtb.759.2024.05.08.10.09.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 May 2024 10:09:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-173599-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="M/97oIyG"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-173599-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-173599-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 0C0AF1C21340 for ; Wed, 8 May 2024 17:09:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A2D231E888; Wed, 8 May 2024 17:08:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M/97oIyG" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A18F11118A; Wed, 8 May 2024 17:08:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715188106; cv=none; b=A1Rh5ZwBUoCVB8514mqVvt3Kl0YIvvml0IyTEjlctKDRRCXXV42iq3dRRlDK0yCmCD9Lp4pqdY8V9xZ9ONu+p9CHJzcf2a9726A1B75tegpK3C+FBFfwjD9BI6gStsClhA3obdesplYDnrxYWwsnLNHR2mKnHhOu7H38kpmkBcs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715188106; c=relaxed/simple; bh=YQRZPYaCXuEct0KhtKlB1VbKYC/PdpRAyC+rY6nTboo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eSEin9lSi93la1+nx99k81Gk4h/vWrxmXJxs9aCM4/aVPescBRlcK4hxctNqI12G4S+ldqrvHZ1mDSY0q3n9Drn33eKyKC0UnPDON/1gcfWM26qsoqYK5kYqcsUJ6oAMWkhGxz3OGWvXm/pGvIdHhNpYNSzGTK5vm1aeHfe63Yo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M/97oIyG; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46EB2C113CC; Wed, 8 May 2024 17:08:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715188106; bh=YQRZPYaCXuEct0KhtKlB1VbKYC/PdpRAyC+rY6nTboo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M/97oIyGXnyHRIpjOSRt/dlWmEADUv0KWyfCU1OQsq/uY5BfiGa97FVH1KF2zm267 q/aQH9lwzmEmP7yR1ItHdSUx9riCFbyv+mD7XZr9Yi29G2Pnsn8q7B8FnQXAWvstbT VWWhui77WaQXzE+ONkfuIoj+c7geqwH3nTM0u6rzKPSAh7KWrIoeiKihdfhhRtjOGZ vDVgRYpj+GnzMm8+P4XQn1Uaks6aOe6O9nqMosogzVG0YklpSxUrFtu4qNEStCxXCn xVY25FP006Nfh2kTJf0IxvUxYea0KK44u2cRljjBciWrxg+lfEs2YusVY64Y/ivp6i jvfsRvjq0jU/w== Date: Wed, 8 May 2024 22:32:26 +0530 From: Naveen N Rao To: Puranjay Mohan Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , Hari Bathini , bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, paulmck@kernel.org, puranjay12@gmail.com Subject: Re: [PATCH bpf v2] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH Message-ID: References: <20240508115404.74823-1-puranjay@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240508115404.74823-1-puranjay@kernel.org> On Wed, May 08, 2024 at 11:54:04AM GMT, Puranjay Mohan wrote: > The Linux Kernel Memory Model [1][2] requires RMW operations that have a > return value to be fully ordered. > > BPF atomic operations with BPF_FETCH (including BPF_XCHG and > BPF_CMPXCHG) return a value back so they need to be JITed to fully > ordered operations. POWERPC currently emits relaxed operations for > these. > > We can show this by running the following litmus-test: > > PPC SB+atomic_add+fetch > > { > 0:r0=x; (* dst reg assuming offset is 0 *) > 0:r1=2; (* src reg *) > 0:r2=1; > 0:r4=y; (* P0 writes to this, P1 reads this *) > 0:r5=z; (* P1 writes to this, P0 reads this *) > 0:r6=0; > > 1:r2=1; > 1:r4=y; > 1:r5=z; > } > > P0 | P1 ; > stw r2, 0(r4) | stw r2,0(r5) ; > | ; > loop:lwarx r3, r6, r0 | ; > mr r8, r3 | ; > add r3, r3, r1 | sync ; > stwcx. r3, r6, r0 | ; > bne loop | ; > mr r1, r8 | ; > | ; > lwa r7, 0(r5) | lwa r7,0(r4) ; > > ~exists(0:r7=0 /\ 1:r7=0) > > Witnesses > Positive: 9 Negative: 3 > Condition ~exists (0:r7=0 /\ 1:r7=0) > Observation SB+atomic_add+fetch Sometimes 3 9 > > This test shows that the older store in P0 is reordered with a newer > load to a different address. Although there is a RMW operation with > fetch between them. Adding a sync before and after RMW fixes the issue: > > Witnesses > Positive: 9 Negative: 0 > Condition ~exists (0:r7=0 /\ 1:r7=0) > Observation SB+atomic_add+fetch Never 0 9 > > [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt > [2] https://www.kernel.org/doc/Documentation/atomic_t.txt > > Fixes: 65112709115f ("powerpc/bpf/64: add support for BPF_ATOMIC bitwise operations") > Signed-off-by: Puranjay Mohan Thanks for reporting and fixing this. There are actually four commits that this fixes across ppc32/ppc64: Fixes: aea7ef8a82c0 ("powerpc/bpf/32: add support for BPF_ATOMIC bitwise operations") Fixes: 2d9206b22743 ("powerpc/bpf/32: Add instructions for atomic_[cmp]xchg") Fixes: dbe6e2456fb0 ("powerpc/bpf/64: add support for atomic fetch operations") Fixes: 1e82dfaa7819 ("powerpc/bpf/64: Add instructions for atomic_[cmp]xchg") > --- > Changes in v1 -> v2: > v1: https://lore.kernel.org/all/20240507175439.119467-1-puranjay@kernel.org/ > - Don't emit `sync` for non-SMP kernels as that adds unessential overhead. > --- > arch/powerpc/net/bpf_jit_comp32.c | 12 ++++++++++++ > arch/powerpc/net/bpf_jit_comp64.c | 12 ++++++++++++ > 2 files changed, 24 insertions(+) > > diff --git a/arch/powerpc/net/bpf_jit_comp32.c b/arch/powerpc/net/bpf_jit_comp32.c > index 2f39c50ca729..0318b83f2e6a 100644 > --- a/arch/powerpc/net/bpf_jit_comp32.c > +++ b/arch/powerpc/net/bpf_jit_comp32.c > @@ -853,6 +853,15 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct code > /* Get offset into TMP_REG */ > EMIT(PPC_RAW_LI(tmp_reg, off)); > tmp_idx = ctx->idx * 4; > + /* > + * Enforce full ordering for operations with BPF_FETCH by emitting a 'sync' > + * before and after the operation. > + * > + * This is a requirement in the Linux Kernel Memory Model. > + * See __cmpxchg_u64() in asm/cmpxchg.h as an example. ^^^ Nit... u32 > + */ > + if (imm & BPF_FETCH && IS_ENABLED(CONFIG_SMP)) > + EMIT(PPC_RAW_SYNC()); I think this block should go before the previous two instructions. We use tmp_idx as a label to retry the ll/sc sequence, so we will end up executing the 'sync' operation on a retry here. > /* load value from memory into r0 */ > EMIT(PPC_RAW_LWARX(_R0, tmp_reg, dst_reg, 0)); > > @@ -905,6 +914,9 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct code > > /* For the BPF_FETCH variant, get old data into src_reg */ > if (imm & BPF_FETCH) { > + /* Emit 'sync' to enforce full ordering */ > + if (IS_ENABLED(CONFIG_SMP)) > + EMIT(PPC_RAW_SYNC()); > EMIT(PPC_RAW_MR(ret_reg, ax_reg)); > if (!fp->aux->verifier_zext) > EMIT(PPC_RAW_LI(ret_reg - 1, 0)); /* higher 32-bit */ > diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c > index 79f23974a320..9a077f8acf7b 100644 > --- a/arch/powerpc/net/bpf_jit_comp64.c > +++ b/arch/powerpc/net/bpf_jit_comp64.c > @@ -804,6 +804,15 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct code > /* Get offset into TMP_REG_1 */ > EMIT(PPC_RAW_LI(tmp1_reg, off)); > tmp_idx = ctx->idx * 4; > + /* > + * Enforce full ordering for operations with BPF_FETCH by emitting a 'sync' > + * before and after the operation. > + * > + * This is a requirement in the Linux Kernel Memory Model. > + * See __cmpxchg_u64() in asm/cmpxchg.h as an example. > + */ > + if (imm & BPF_FETCH && IS_ENABLED(CONFIG_SMP)) > + EMIT(PPC_RAW_SYNC()); Same here. I'll try and give this a test tomorrow. - Naveen