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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2346C64E7C for ; Wed, 2 Dec 2020 06:00:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6BE1722202 for ; Wed, 2 Dec 2020 06:00:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728559AbgLBF7z (ORCPT ); Wed, 2 Dec 2020 00:59:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726402AbgLBF7z (ORCPT ); Wed, 2 Dec 2020 00:59:55 -0500 Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E992DC0617A6; Tue, 1 Dec 2020 21:59:14 -0800 (PST) Received: by mail-yb1-xb41.google.com with SMTP id x17so568991ybr.8; Tue, 01 Dec 2020 21:59:14 -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=F94yO1pwn3xIo22l06GSRvMTzN1e1hNRNmIShFlxrFg=; b=pDgtDxwd9en7BP/yXgYVNIbfwdxQtUIuwHWBkQJ3tfIXoiqveXReo80hcEaTrNRj9m 4KUD1Q5CFPRcDuy3pfmd5mYiK84txeNb04sCEYNC9AuMqLcNCWl8lIc0t8p5a3v7MPpX R1Ay+QL1HUEio+BcjWcLmXuzUU748MtLnWwaJuaPDNyiwNCK02zsTBCMQdD99rieVLY+ 7btSHYeUJLLhHkiFha+u7RiX/d8Y44IJVvTAd3ao04wSKIx2anlC1aLSOGcW3fq93VHY SKtkAzK7SRoaO0TCvDKU+7rnf0+7gjz7gxIK+XfSZsOyhqCGQq8r8sQy8xdQoOAOubpU 8TQA== 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=F94yO1pwn3xIo22l06GSRvMTzN1e1hNRNmIShFlxrFg=; b=tCupU2q9+nTV6D246bZ944K8Qd3+ph3OSS3EcxVYjsk1PiqkCeWh7RZOpip3OONWnc 8pNi1ZekAZYcuBuaS1DMj/zrP7fXAwDd2Byha+XTSjFEYPLJsO2rlMZunqlAITW+V+j3 bBvqVEYjEOCQywYxjuPhOqEkGLtuWCujRlZuORndwxFzxTnxw4bdbEKpzdiw44ghQ4/n j/uT+JBdkzV6EJmw2cr9XLsfWY2rKeUYl5QuuyxiZSLCExSiIKlYKYc3PntayUzhGyQk BzLKbsvMkRe9mPVtKnFEumz1Te8roUWVHRYXJ5vFkNo8ksXUl2LAnlWKgmwvvrX+DT0a CLFA== X-Gm-Message-State: AOAM533bD64aiKJTdlU+TZg87qvqkWvXquCh9udGZcUDvKOSfebuSecy it4mMhIGg4+jqEbC1kxvvwx+euWkH0mSdefnt/4= X-Google-Smtp-Source: ABdhPJyhO2ALk+vxLjnUVqxXD+cISn4ojLs4nxlCLVf4SdZXp1WOe1coMg/ZgyLoJPrl9B9Davy3ZqH5AAif/9ROpKo= X-Received: by 2002:a25:2845:: with SMTP id o66mr1599455ybo.260.1606888754244; Tue, 01 Dec 2020 21:59:14 -0800 (PST) MIME-Version: 1.0 References: <20201127175738.1085417-1-jackmanb@google.com> <829353e6-d90a-a91a-418b-3c2556061cda@fb.com> <20201129014000.3z6eua5pcz3jxmtk@ast-mbp> <4fa9f8cf-aaf8-a63c-e0ca-7d4c83b01578@fb.com> <31a67edd-4837-cfd3-c9fe-a6942ebd87bb@fb.com> <5fc72beede900_15eb720850@john-XPS-13-9370.notmuch> In-Reply-To: <5fc72beede900_15eb720850@john-XPS-13-9370.notmuch> From: Andrii Nakryiko Date: Tue, 1 Dec 2020 21:59:03 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 00/13] Atomics for eBPF To: John Fastabend Cc: Yonghong Song , Alexei Starovoitov , Brendan Jackman , bpf , Alexei Starovoitov , Daniel Borkmann , KP Singh , Florent Revest , open list , Jann Horn Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 1, 2020 at 9:53 PM John Fastabend wrote: > > Yonghong Song wrote: > > > > > > [...] > > > > Great, this means that all existing valid uses of > > > __sync_fetch_and_add() will generate BPF_XADD instructions and will > > > work on old kernels, right? > > > > That is correct. > > > > > > > > If that's the case, do we still need cpu=v4? The new instructions are > > > *only* going to be generated if the user uses previously unsupported > > > __sync_fetch_xxx() intrinsics. So, in effect, the user consciously > > > opts into using new BPF instructions. cpu=v4 seems like an unnecessary > > > tautology then? > > > > This is a very good question. Essentially this boils to when users can > > use the new functionality including meaningful return value of > > __sync_fetch_and_add(). > > (1). user can write a small bpf program to test the feature. If user > > gets a failed compilation (fatal error), it won't be supported. > > Otherwise, it is supported. > > (2). compiler provides some way to tell user it is safe to use, e.g., > > -mcpu=v4, or some clang macro suggested by Brendan earlier. > > > > I guess since kernel already did a lot of feature discovery. Option (1) > > is probably fine. > > For option (2) we can use BTF with kernel version check. If kernel is > greater than kernel this lands in we use the the new instructions if > not we use a slower locked version. That should work for all cases > unless someone backports patches into an older case. Two different things: Clang support detection and kernel support detection. You are talking about kernel detection, I and Yonghong were talking about Clang detection and explicit cpu=v4 opt-in. For kernel detection, if there is an enum value or type that gets added along the feature, then with CO-RE built-ins it's easy to detect and kernel dead code elimination will make sure that unsupported instructions won't trip up the BPF verifier. Still need Clang support to compile the program in the first place, though. If there is no such BTF-based way to check, it is still possible to try to load a trivial BPF program with __sync_fech_and_xxx() to do feature detection and then use .rodata to turn off code paths relying on a new instruction set. > > At least thats what I'll probably end up wrapping in a helper function.