From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) (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 B69B5EC5; Tue, 14 May 2024 01:09:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=150.107.74.76 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715648956; cv=none; b=gioD83WxgL8NhBuSjnYvrIIRD/Z5XvKVldZA51hOWdWgk3zJ+W7QeyVtrgMdIB5CRTvFcMNGWO3XwAvhySu30eVCv+OVBQKXHaun6ajDY8NUWx04BjMVVoLQrtvv2MQko4rY7Ed8BYBzbnKRuk1TEJy6nLhPvcmzYf9Vm1VSiNQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715648956; c=relaxed/simple; bh=Z0a9zo/oD7Fzoeh2HMvsQbMyP/a4DTsMNsBtVleFWZA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=VF6viBxU4cViOEtn5FxgnGBMmU11NcaBkS5YrfUlv3Plm0GNPNSKISCbPaGTI4olYSY0W2gMOxjoQoQgguxbikKO7TnaltQMzzRFbn/uDt4tQkX9G+xdya/doJoneM+kJAVX7AS4IWlLLH1MtJIuPKdDGdrxpGa1VYSFmSEkUXQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au; spf=pass smtp.mailfrom=ellerman.id.au; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b=nhWdX3An; arc=none smtp.client-ip=150.107.74.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ellerman.id.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b="nhWdX3An" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1715648950; bh=cJZZq6BaqUzfoKYWBZ/95aiewNAVNaflLJy9ncQn21Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nhWdX3AnX/lfpTM/3msxKX1vr3ahC0e0aj5/uYWopsMwiOJhDV5Nj/9I89GXiJ3Q/ 6aWx/cOv3OZ5Xo/4WZgD4+v03yGXP9Y07XFHKiUgCf6W10BmHEh3ar0Z6HIhINcKMB Nvk9huz4bBVvkHluHiCMpZ+lJHDL8VkSbohw0wrxlC3wLUTp0h+L99ji3VJ1t4ZXCl Irb8bpFJpVczlOs7DFojFAjJN7zOYxbbCkp2/BPs86cHpna5tdzFe7teI5Zjk/pgWb lkRs4aODolq4b60AuGvlOMP8nfOQuE2sioi7ZEaPvpXugmAHNmKLhYBf4LxJH1xpS8 esjU/uxMK+iMQ== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4VddY15HGZz4wc3; Tue, 14 May 2024 11:09:09 +1000 (AEST) From: Michael Ellerman To: Puranjay Mohan , Naveen N Rao 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 , 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 Subject: Re: [PATCH bpf v3] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH In-Reply-To: References: <20240513100248.110535-1-puranjay@kernel.org> Date: Tue, 14 May 2024 11:09:07 +1000 Message-ID: <87h6f1w66k.fsf@mail.lhotse> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Puranjay Mohan writes: > Naveen N Rao writes: >> On Mon, May 13, 2024 at 10:02:48AM 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") >> >> As I noted in v2, I think that is the wrong commit. This fixes the below > > Sorry for missing this. Would this need another version or your message > below will make it work with the stable process? No need for another version. b4 should pick up those tags, or if not I'll add them by hand. cheers From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C8CA2C25B78 for ; Tue, 14 May 2024 01:09:59 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=nhWdX3An; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4VddYy28S1z3cX7 for ; Tue, 14 May 2024 11:09:58 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=nhWdX3An; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4VddY61v68z30TL for ; Tue, 14 May 2024 11:09:14 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1715648950; bh=cJZZq6BaqUzfoKYWBZ/95aiewNAVNaflLJy9ncQn21Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nhWdX3AnX/lfpTM/3msxKX1vr3ahC0e0aj5/uYWopsMwiOJhDV5Nj/9I89GXiJ3Q/ 6aWx/cOv3OZ5Xo/4WZgD4+v03yGXP9Y07XFHKiUgCf6W10BmHEh3ar0Z6HIhINcKMB Nvk9huz4bBVvkHluHiCMpZ+lJHDL8VkSbohw0wrxlC3wLUTp0h+L99ji3VJ1t4ZXCl Irb8bpFJpVczlOs7DFojFAjJN7zOYxbbCkp2/BPs86cHpna5tdzFe7teI5Zjk/pgWb lkRs4aODolq4b60AuGvlOMP8nfOQuE2sioi7ZEaPvpXugmAHNmKLhYBf4LxJH1xpS8 esjU/uxMK+iMQ== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4VddY15HGZz4wc3; Tue, 14 May 2024 11:09:09 +1000 (AEST) From: Michael Ellerman To: Puranjay Mohan , Naveen N Rao Subject: Re: [PATCH bpf v3] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH In-Reply-To: References: <20240513100248.110535-1-puranjay@kernel.org> Date: Tue, 14 May 2024 11:09:07 +1000 Message-ID: <87h6f1w66k.fsf@mail.lhotse> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Hao Luo , linux-kernel@vger.kernel.org, Jiri Olsa , Daniel Borkmann , Eduard Zingerman , paulmck@kernel.org, linuxppc-dev@lists.ozlabs.org, John Fastabend , Alexei Starovoitov , Nicholas Piggin , Andrii Nakryiko , "Aneesh Kumar K.V" , Song Liu , Stanislav Fomichev , Yonghong Song , KP Singh , bpf@vger.kernel.org, Martin KaFai Lau , Hari Bathini Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Puranjay Mohan writes: > Naveen N Rao writes: >> On Mon, May 13, 2024 at 10:02:48AM 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") >> >> As I noted in v2, I think that is the wrong commit. This fixes the below > > Sorry for missing this. Would this need another version or your message > below will make it work with the stable process? No need for another version. b4 should pick up those tags, or if not I'll add them by hand. cheers