Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3050338pxu; Tue, 8 Dec 2020 02:03:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzUNeT9xL44fg5lnGUCxP75TY5/w6YxxfXIDMQPSSJ9ISjlpHn/dTHSCP1/Azk3VDCJ9+Ab X-Received: by 2002:a17:906:168f:: with SMTP id s15mr22059102ejd.180.1607421813064; Tue, 08 Dec 2020 02:03:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607421813; cv=none; d=google.com; s=arc-20160816; b=vsQGp6MB246OxoYiG40X9SV2PrekRwwu1/3hdDzBga/NZ+NpoNzeV+4R6nZwrkzLNZ CnSl0ljQTB5RlBwJ83rhmsz5BcF8cbhz9RlMzSfkUiOUM946qr0UMa3JMryJ5lxEPvBK QljiNzja8espLDbf+c6rcQnJsFml2C54TcdyNnFcp2RZW3OrwN+R9pWiHWkxJ3Gu/Mmk U6PPFlk3Xvmxgbgjx0/rDpWTvC7yWzn8Lcjh3+Q9j2Vl7UkyUDD07z7qqLBqqVkFWIfX R/cMmidRsNxUo6l0waV2hdfLpp9mA+140L7unmRQ38opN1M3amor9J3QBV6aQw+NjVct 8o2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=QdGmwva9RtqTY7a7GN4dBmF3gJOdWFsFlLtWdXLRLeA=; b=z91lEgvSbifI62VgQeXQkJ2FfPIUSude62Ivpqcl4EZlphP99axo/1IeZu7g1hvTTh QJk0mtuB9eaxAl5VTy4rZC8elHf6Rtje8Ed2kx2zE3UgYmiTH3HzLL/J7F393PZQBNHl 5hFOeISkcZXpKjsgMG93njRXolDnR2BhTnFplMRjK6lbaOWIE/tU08tKQuIY6+1L6PG7 3nepliXpFVGq8zWud7RYAuLejAyyTBN5vJwkvAdOR8kHZ6xjbDK66+ugzfOIiTt1whom 72KiSsOUZlc1Ea2dmgyRckj2ZO4GvV8G5oRVFbvURPJXOWu8y78h0TSlyoUT5JPXj/RB fiIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XAuv5QEe; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q22si8109294ejy.29.2020.12.08.02.03.09; Tue, 08 Dec 2020 02:03:33 -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=@google.com header.s=20161025 header.b=XAuv5QEe; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727950AbgLHKA0 (ORCPT + 99 others); Tue, 8 Dec 2020 05:00:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727096AbgLHKA0 (ORCPT ); Tue, 8 Dec 2020 05:00:26 -0500 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D6D2C061749 for ; Tue, 8 Dec 2020 01:59:45 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id u12so15646502wrt.0 for ; Tue, 08 Dec 2020 01:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=QdGmwva9RtqTY7a7GN4dBmF3gJOdWFsFlLtWdXLRLeA=; b=XAuv5QEeW/kEMbA4SLlD2kgsjqPXZd+4y+wc51LFw4CWcP0Jaw8W8hAAjawk115SEL YxiSL7k1uZLUanxDFQtqNWDABvLkbAeJPJTGqyQ7vSXDjd7TTTJQSn28bbNJCtoI1eZr muvqOnohKVlZlK1iLAwUeRmW7I7Xq8FSVRfnAstDhJDVwBHW3I5DukXufOms+KY72s/1 FcbvU+YYHE5Q2lDFWQZ7UMnCFtqqDQP16Tjx0x60U56vmHqzshWTsYY/9cnOL2zerwX4 VrEN77a0Xvg/S1n4OiQF+1dycTK2i1LDxE14ec7Wd+8UIYm6E+ej+RUWBPL3r5SMS4ew xikg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=QdGmwva9RtqTY7a7GN4dBmF3gJOdWFsFlLtWdXLRLeA=; b=j1PzacNUK8eEIQJpdZP7NCNgKhPUHfI/ckVvRmPHcpMvbSF0qjzDZCS+kuF/QTJbBp xhC6djObqWJIVxA8y5eIq/T+QZVryrFIz9GixsC0nNjmGjkM1Dr4gxU96Rjhs6RX7pSb MjOLdisKpMzXxFgP2Bcb3XgePhD00ugBneRpBAWajVfkCRNmxS1Td5lF+A0XGWu9sFTc isb1IBBJwleC/5Gciu6rMWmQOqaOy6+QrW912UK3DmFi7qZXKnC1omAJoboCpMXiSsuo NldxiyfHO9NvdnlHWRGaQjluFqKdA6+tQ2lZ5MPm8ewRmJFuNKBJIr4gU87juvBXGMUS owLA== X-Gm-Message-State: AOAM530xK3ucDTdpvg8D//KtC+SXPPrsUFyv3jkHT+qS/VQMGM224T+p bcca9k/ACVoQShf4zmLhRrgY6A== X-Received: by 2002:adf:f6c8:: with SMTP id y8mr22962698wrp.59.1607421584172; Tue, 08 Dec 2020 01:59:44 -0800 (PST) Received: from google.com (203.75.199.104.bc.googleusercontent.com. [104.199.75.203]) by smtp.gmail.com with ESMTPSA id f7sm3816543wmc.1.2020.12.08.01.59.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Dec 2020 01:59:43 -0800 (PST) Date: Tue, 8 Dec 2020 09:59:39 +0000 From: Brendan Jackman To: John Fastabend Cc: bpf@vger.kernel.org, Alexei Starovoitov , Yonghong Song , Daniel Borkmann , KP Singh , Florent Revest , linux-kernel@vger.kernel.org, Jann Horn Subject: Re: [PATCH bpf-next v4 06/11] bpf: Add BPF_FETCH field / create atomic_fetch_add instruction Message-ID: References: <20201207160734.2345502-1-jackmanb@google.com> <20201207160734.2345502-7-jackmanb@google.com> <5fcf0fbcc8aa8_9ab320853@john-XPS-13-9370.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fcf0fbcc8aa8_9ab320853@john-XPS-13-9370.notmuch> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 07, 2020 at 09:31:40PM -0800, John Fastabend wrote: > Brendan Jackman wrote: > > The BPF_FETCH field can be set in bpf_insn.imm, for BPF_ATOMIC > > instructions, in order to have the previous value of the > > atomically-modified memory location loaded into the src register > > after an atomic op is carried out. > > > > Suggested-by: Yonghong Song > > Signed-off-by: Brendan Jackman > > --- > > I like Yonghong suggestion > > #define BPF_ATOMIC_FETCH_ADD(SIZE, DST, SRC, OFF) \ > BPF_ATOMIC(SIZE, DST, SRC, OFF, BPF_ADD | BPF_FETCH) > > otherwise LGTM. One observation to consider below. > > Acked-by: John Fastabend > > > arch/x86/net/bpf_jit_comp.c | 4 ++++ > > include/linux/filter.h | 1 + > > include/uapi/linux/bpf.h | 3 +++ > > kernel/bpf/core.c | 13 +++++++++++++ > > kernel/bpf/disasm.c | 7 +++++++ > > kernel/bpf/verifier.c | 33 ++++++++++++++++++++++++--------- > > tools/include/linux/filter.h | 11 +++++++++++ > > tools/include/uapi/linux/bpf.h | 3 +++ > > 8 files changed, 66 insertions(+), 9 deletions(-) > > [...] > > > @@ -3652,8 +3656,20 @@ static int check_atomic(struct bpf_verifier_env *env, int insn_idx, struct bpf_i > > return err; > > > > /* check whether we can write into the same memory */ > > - return check_mem_access(env, insn_idx, insn->dst_reg, insn->off, > > - BPF_SIZE(insn->code), BPF_WRITE, -1, true); > > + err = check_mem_access(env, insn_idx, insn->dst_reg, insn->off, > > + BPF_SIZE(insn->code), BPF_WRITE, -1, true); > > + if (err) > > + return err; > > + > > + if (!(insn->imm & BPF_FETCH)) > > + return 0; > > + > > + /* check and record load of old value into src reg */ > > + err = check_reg_arg(env, insn->src_reg, DST_OP); > > This will mark the reg unknown. I think this is fine here. Might be nice > to carry bounds through though if possible Ah, I hadn't thought of this. I think if I move this check_reg_arg to be before the first check_mem_access, and then (when BPF_FETCH) set the val_regno arg to load_reg, then the bounds from memory would get propagated back to the register: if (insn->imm & BPF_FETCH) { if (insn->imm == BPF_CMPXCHG) load_reg = BPF_REG_0; else load_reg = insn->src_reg; err = check_reg_arg(env, load_reg, DST_OP); if (err) return err; } else { load_reg = -1; } /* check wether we can read the memory */ err = check_mem_access(env, insn_index, insn->dst_reg, insn->off BPF_SIZE(insn->code), BPF_READ, load_reg, // <-- true); Is that the kind of thing you had in mind? > > + if (err) > > + return err; > > + > > + return 0; > > } > >