Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2485357pxb; Mon, 18 Jan 2021 20:50:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJwMxrdtMZodqFC1+0xP3Icpp6Ukl1rsafyv6E1Bbo/LFq7pbOAiw09U1k3A0Y1NiaJGXMTB X-Received: by 2002:a17:906:c00c:: with SMTP id e12mr1750844ejz.103.1611031811745; Mon, 18 Jan 2021 20:50:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611031811; cv=none; d=google.com; s=arc-20160816; b=Kkk6fHpyTbFdl6i8f/OF1FPJvoo7cLUg3X6jAodquSmj/bXg9Po0PlBBiULLVDoO64 ODv3VvwMSHghbL/mZNi/QMPIBnPWc7KgHNspucgzoHiEZmeYKpYF4Iu/3DMQK+Po1rTu fst7sc4qKJLYMiPcgAa5Qjpl4M6ORZ7hXpGtnex8IeS70fMiYLfY4AcUm9ky8bohEb4Z F1xwAwmElAn/J0Vv6ef8BEKrUi3F2jchdmYxluBqGBu4N7Z1AveoLJxmZ5XLqZFa7JiV Cvnbme1Jybj8Rd91gqoaatgrvHcaXuEThOqBdkyWQPEskkOr61E89qwnetkdxhiE0+wX 2+Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Dn0ytLTJxb3OwEjsd6jBPmWuzBnw0hCPCVvXeaDxuoM=; b=uHEaU3H0GB/SsaDMXyNmRkTFOeDMPDW4ENLcP90D63yLBmrV8o6UUZpWB8aP3pNqlL 2u5HDXk8rBbNHrNDUjE8nj/Pe8Rko+etbhRcblpXyArEXk2noITSn5+vD1rRfxH4peVm 9TM384Oc99h+0CQ6wVOvc7Cp6uqILxPBcgz7KBOiRX22KniNCtARNyfoaEdtArnbHghE +nDa1x031j+UbJOcpQK0Osvx9cq1FzaX7JeYBpXtMAKCiiHa83btRc+UAZQZvkj9LNGQ fgYjA9d8Se41wXWjCcP4wmTKjQA61LUNrnQyV9yaLfYDfUX6ZKF8TehpijLhJ5fyMhRD /INA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bW39eLT1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n10si7185978eja.493.2021.01.18.20.49.48; Mon, 18 Jan 2021 20:50:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bW39eLT1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406931AbhARRT0 (ORCPT + 99 others); Mon, 18 Jan 2021 12:19:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393592AbhARRSO (ORCPT ); Mon, 18 Jan 2021 12:18:14 -0500 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B816BC061574; Mon, 18 Jan 2021 09:17:31 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id q2so32525962iow.13; Mon, 18 Jan 2021 09:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dn0ytLTJxb3OwEjsd6jBPmWuzBnw0hCPCVvXeaDxuoM=; b=bW39eLT1IHoKEwm6HWNf9AYzqhTi/mZ9+2fxn14xHZqSISYUhPG1T66wiuaCyBA5DN TsxjDHxI1/md/D5Vn382HXRXKk+Oor2cGSuvMbp2TipohpXJBBMci3xyospVygPn2qvM 1YyQIjDJOWKuVi+ZjAjRAXwFSmBVQETa1X7gyWxH+AwL3NR+bVyt2AbZJgOnboAZYMBa LMKD+74Jd0g5KLEbU0Dn2gc/ffGbyfvQ1mhI0p98o/5EXRmTpkHr+i7vWNQsdoEY1vZR 9f9wn0byiDn5oWYBZVCKVKaaZjpWlJ0qFqN85xE3Zhsei9aGBvffUyTJHm9hQJeWETXe B79w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dn0ytLTJxb3OwEjsd6jBPmWuzBnw0hCPCVvXeaDxuoM=; b=Q+vZSqtFBgXAc47OOcTXWDblnlyciCr/PqgvngM082aTSmgkE/92DlFd5T8RqpZJA4 gKmOyDBX3iIxFqi1XhUVJ7qYnFm9TznZcJy/9C5hhv/NfMHjg/p1buQn96M5plGhK6u6 cNOU0Z/x37R2lpI46grC4j4J+za1tuioNsh1Mm95iZvZvOPamHzFxj/nVJWSoADEx645 yRSsbyb04e1hn7OpvStK/LHuwqT+Yp6cMAfplLXq3kAjvq6KS1Le7k9kTrZrlmSqZT+d pDiCliHz5wPKxgIwaagj2TLv8GSAFJZlQgch3OgqwQVrRPeeAEzR1XOOFqq97A0FOGfs /n+A== X-Gm-Message-State: AOAM533+8sUCy8XhUGWNKOEyXmEjlvfVBuxXNI2WWzV/gQkCrnW79g8X FeocVw5W2lmQH1sfvPx9wBFIesoQfiZONnXc8YU= X-Received: by 2002:a05:6e02:1aa8:: with SMTP id l8mr192128ilv.251.1610990250995; Mon, 18 Jan 2021 09:17:30 -0800 (PST) MIME-Version: 1.0 References: <20210118155735.532663-1-jackmanb@google.com> <20210118155735.532663-2-jackmanb@google.com> In-Reply-To: <20210118155735.532663-2-jackmanb@google.com> From: Lukas Bulwahn Date: Mon, 18 Jan 2021 18:17:20 +0100 Message-ID: Subject: Re: [PATCH bpf-next v2 1/2] docs: bpf: Fixup atomics markup To: Brendan Jackman Cc: bpf@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , KP Singh , Florent Revest , Linux Kernel Mailing List , "open list:DOCUMENTATION" , Jonathan Corbet Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 18, 2021 at 4:59 PM Brendan Jackman wrote: > > This fixues up the markup to fix a warning, be more consistent with s/fixues/fixes/ ? > use of monospace, and use the correct .rst syntax for (* instead > of _). > > NB this conflicts with Lukas' patch at [1], which just fixes the > warning. The scope of this one is a little broader. > > [1] https://lore.kernel.org/bpf/CA+i-1C3cEXqxcXfD4sibQfx+dtmmzvOzruhk8J5pAw3g5v=KgA@mail.gmail.com/T/#t > As I wrote in my patch, I did minimal changes. Your bit more extensive changes make sense. I suggest dropping this comment above starting from NB and the link; it is not relevant for the history. You can of course move it below the "---"; so it is not picked up into the git history. Other than that: Reviewed-by: Lukas Bulwahn > Signed-off-by: Brendan Jackman > --- > Documentation/networking/filter.rst | 19 ++++++++++--------- > 1 file changed, 10 insertions(+), 9 deletions(-) > > diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst > index f6d8f90e9a56..4c2bb4c6364d 100644 > --- a/Documentation/networking/filter.rst > +++ b/Documentation/networking/filter.rst > @@ -1048,12 +1048,12 @@ Unlike classic BPF instruction set, eBPF has generic load/store operations:: > Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. > > It also includes atomic operations, which use the immediate field for extra > -encoding. > +encoding:: > > .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg > .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg > > -The basic atomic operations supported are: > +The basic atomic operations supported are:: > > BPF_ADD > BPF_AND > @@ -1066,12 +1066,12 @@ memory location addresed by ``dst_reg + off`` is atomically modified, with > immediate, then these operations also overwrite ``src_reg`` with the > value that was in memory before it was modified. > > -The more special operations are: > +The more special operations are:: > > BPF_XCHG > > This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg + > -off``. > +off``. :: > > BPF_CMPXCHG > > @@ -1081,18 +1081,19 @@ before is loaded back to ``R0``. > > Note that 1 and 2 byte atomic operations are not supported. > > -Except ``BPF_ADD`` _without_ ``BPF_FETCH`` (for legacy reasons), all 4 byte > +Except ``BPF_ADD`` *without* ``BPF_FETCH`` (for legacy reasons), all 4 byte > atomic operations require alu32 mode. Clang enables this mode by default in > architecture v3 (``-mcpu=v3``). For older versions it can be enabled with > ``-Xclang -target-feature -Xclang +alu32``. > > -You may encounter BPF_XADD - this is a legacy name for BPF_ATOMIC, referring to > -the exclusive-add operation encoded when the immediate field is zero. > +You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, > +referring to the exclusive-add operation encoded when the immediate field is > +zero. > > -eBPF has one 16-byte instruction: BPF_LD | BPF_DW | BPF_IMM which consists > +eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which consists > of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as single > instruction that loads 64-bit immediate value into a dst_reg. > -Classic BPF has similar instruction: BPF_LD | BPF_W | BPF_IMM which loads > +Classic BPF has similar instruction: ``BPF_LD | BPF_W | BPF_IMM`` which loads > 32-bit immediate value into a register. > > eBPF verifier > -- > 2.30.0.284.gd98b1dd5eaa7-goog >