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=-9.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 00EB0C10F0E for ; Fri, 12 Apr 2019 22:00:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C7C892084D for ; Fri, 12 Apr 2019 22:00:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="SDh96Nim" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727259AbfDLWAm (ORCPT ); Fri, 12 Apr 2019 18:00:42 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:34082 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727232AbfDLWAO (ORCPT ); Fri, 12 Apr 2019 18:00:14 -0400 Received: by mail-wr1-f66.google.com with SMTP id p10so13758540wrq.1 for ; Fri, 12 Apr 2019 15:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=J0YL3VY81ZYkLm7FFiGr50XaGEO0Un8tKpiZShOimgc=; b=SDh96NimQGVnmCD3G9uU2gLWVqjy9PUzYzOKCNA6GsUdgbpKHh1HXSxq2//xnxe2kq bae3Mb6V5JVSgLVbS81jJElc8tXGib5xL3QCGfgDT5OsJhK7pV0uD10aS67CQqGOEmwb Wgf94ETAYN5ZKh1rAFfUGqvdN6iaX49o063lfDMkp1kqbrV1IstcaEaLGMYfkg9EShp4 vInfSrheI4VLH6mgzkECRduXU9JPOLbqeKLd4t+CVXBJoEscKds60Lgmxy9MT4yQKWzC qVwKITwc9TXnce39DbY893xlsxGHwpi3e9K3L7QBr8Bm73enR+itsq31ujGt9KQ9HuDg H2cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=J0YL3VY81ZYkLm7FFiGr50XaGEO0Un8tKpiZShOimgc=; b=hzfSlOPz2Tk+PK1ZrLY2zObTWLutt43gEsgFVtaCm1PLVgJLE87zbRF1gZyV1REHlv gX0nnGsCHL/Rpw+xb6HoctjkMHHDi1EfGsDy5KJ9vDw5EZptRT4MwPrNutuBxEVgJPUU av3LPfQm2ucpGwP+75FeObWmngtN0f+VMqX8DXEi6kJbL6LCkiMnmhF0uCUKlxmPYFFT eFKQ4zKO5SxrtWj8oIHaSId3W0kJed0u88OrdDcP1LGnwtFDq0eYazDrCDhSiMOjOb2Z qoDwPyWMO5E+gzLrRf/HEBp2O+crs/LY+iGITx5ya9cElSwuL2rozHcBrLU1TMBOaH6L sn3g== X-Gm-Message-State: APjAAAWDkLX37HVE4LDfF3YcPD/LPeZJKqABG0AlH5N4/iIoDvPdDVaN NpemuBuKhwOYJVcWl4yYNJOldg== X-Google-Smtp-Source: APXvYqyXd9E5Vkbz6d0Fzbn/JzQzT/dPfV/l1mQlr1XZLg08V7PQp2BfBlAq1/bw/DW+iC8ZYMyz9w== X-Received: by 2002:adf:fec3:: with SMTP id q3mr38000727wrs.173.1555106412288; Fri, 12 Apr 2019 15:00:12 -0700 (PDT) Received: from cbtest28.netronome.com ([217.38.71.146]) by smtp.gmail.com with ESMTPSA id f1sm8490764wml.28.2019.04.12.15.00.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Apr 2019 15:00:11 -0700 (PDT) From: Jiong Wang To: alexei.starovoitov@gmail.com, daniel@iogearbox.net Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, oss-drivers@netronome.com, Jiong Wang Subject: [PATCH v3 bpf-next 09/19] bpf: introduce new bpf prog load flags "BPF_F_TEST_RND_HI32" Date: Fri, 12 Apr 2019 22:59:42 +0100 Message-Id: <1555106392-20117-10-git-send-email-jiong.wang@netronome.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1555106392-20117-1-git-send-email-jiong.wang@netronome.com> References: <1555106392-20117-1-git-send-email-jiong.wang@netronome.com> Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org x86_64 and AArch64 perhaps are two arches that running bpf testsuite frequently, however the zero extension insertion pass is not enabled for them because of their hardware support. It is critical to guarantee the pass correction as it is supposed to be enabled at default for a couple of other arches, for example PowerPC, SPARC, arm, NFP etc. Therefore, it would be very useful if there is a way to test this pass on for example x86_64. The test methodology employed by this set is "poisoning" useless bits. High 32-bit of a definition is randomized if it is identified as not used by any later instructions. Such randomization is only enabled under testing mode which is gated by the new bpf prog load flags "BPF_F_TEST_RND_HI32". Suggested-by: Alexei Starovoitov Signed-off-by: Jiong Wang --- include/uapi/linux/bpf.h | 18 ++++++++++++++++++ kernel/bpf/syscall.c | 4 +++- tools/include/uapi/linux/bpf.h | 18 ++++++++++++++++++ 3 files changed, 39 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index c26be24..89c85a3 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -258,6 +258,24 @@ enum bpf_attach_type { */ #define BPF_F_ANY_ALIGNMENT (1U << 1) +/* BPF_F_TEST_RND_HI32 is used in BPF_PROG_LOAD command for testing purpose. + * Verifier does sub-register def/use analysis and identifies instructions whose + * def only matters for low 32-bit, high 32-bit is never referenced later + * through implicit zero extension. Therefore verifier notifies JIT back-ends + * that it is safe to ignore clearing high 32-bit for these instructions. This + * saves some back-ends a lot of code-gen. However such optimization is not + * necessary on some arches, for example x86_64, arm64 etc, whose JIT back-ends + * hence hasn't used verifier's analysis result. But, we really want to have a + * way to be able to verify the correctness of the described optimization on + * x86_64 on which testsuites are frequently exercised. + * + * So, this flag is introduced. Once it is set, verifier will randomize high + * 32-bit for those instructions who has been identified as safe to ignore them. + * Then, if verifier is not doing correct analysis, such randomization will + * regress tests to expose bugs. + */ +#define BPF_F_TEST_RND_HI32 (1U << 2) + /* When BPF ldimm64's insn[0].src_reg != 0 then this can have * two extensions: * diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 92c9b8a..abe2804 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -1600,7 +1600,9 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr) if (CHECK_ATTR(BPF_PROG_LOAD)) return -EINVAL; - if (attr->prog_flags & ~(BPF_F_STRICT_ALIGNMENT | BPF_F_ANY_ALIGNMENT)) + if (attr->prog_flags & ~(BPF_F_STRICT_ALIGNMENT | + BPF_F_ANY_ALIGNMENT | + BPF_F_TEST_RND_HI32)) return -EINVAL; if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index c26be24..89c85a3 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -258,6 +258,24 @@ enum bpf_attach_type { */ #define BPF_F_ANY_ALIGNMENT (1U << 1) +/* BPF_F_TEST_RND_HI32 is used in BPF_PROG_LOAD command for testing purpose. + * Verifier does sub-register def/use analysis and identifies instructions whose + * def only matters for low 32-bit, high 32-bit is never referenced later + * through implicit zero extension. Therefore verifier notifies JIT back-ends + * that it is safe to ignore clearing high 32-bit for these instructions. This + * saves some back-ends a lot of code-gen. However such optimization is not + * necessary on some arches, for example x86_64, arm64 etc, whose JIT back-ends + * hence hasn't used verifier's analysis result. But, we really want to have a + * way to be able to verify the correctness of the described optimization on + * x86_64 on which testsuites are frequently exercised. + * + * So, this flag is introduced. Once it is set, verifier will randomize high + * 32-bit for those instructions who has been identified as safe to ignore them. + * Then, if verifier is not doing correct analysis, such randomization will + * regress tests to expose bugs. + */ +#define BPF_F_TEST_RND_HI32 (1U << 2) + /* When BPF ldimm64's insn[0].src_reg != 0 then this can have * two extensions: * -- 2.7.4