From patchwork Wed Apr 10 19:50:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiong Wang X-Patchwork-Id: 1083586 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=netronome.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="gUZFEknY"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 44fZXl4Ln7z9s5c for ; Thu, 11 Apr 2019 05:51:19 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726763AbfDJTux (ORCPT ); Wed, 10 Apr 2019 15:50:53 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:41252 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726723AbfDJTuw (ORCPT ); Wed, 10 Apr 2019 15:50:52 -0400 Received: by mail-wr1-f66.google.com with SMTP id r4so4344507wrq.8 for ; Wed, 10 Apr 2019 12:50:50 -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=nd5AQSgpxrFUG35Pr+nHitfEvY8VkzebUPhOXd6teig=; b=gUZFEknY3MItC7K9kj8CFSBReHYGGcB7unrRewYMSdofmO0j9/N+ntkmbyN9KhKMqs Jfwpdf1dA7Xij5YNtgNUy5vDdL5TeoPMevFoW8VVCTqNjkozFMuxEZ+P0Ew6lKKZRpv4 igJGj+GKpLP4uG5g+ii6SVVDvk07c8BpCN3HW0QoZgivTyHcAsT3yBk3IP0bE02obPW9 Ol4PKyfmOBryL+FCQ0d0v8kMaKkaIC/FIcgIdW+ienmzFPXnHyNk7VvR2YdkvW0TmB/k IWRxIBHlbliJNCAheaBsJg+1JO3Yvjjo64v+m1/6WpjFPAtgmIT3rWx4/W0sMiSkvqCt IZBQ== 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=nd5AQSgpxrFUG35Pr+nHitfEvY8VkzebUPhOXd6teig=; b=klfoL+MNxvM9fvFUvF0Oghmn8XyVNz4Y9Y/D7xCXaAhV/2Gkf6Xs2hNPUMzjyHYRDb pThMEAo/nxrZ89kurG3wHrj2kiS+5IHAiqSQp6dApZGik5A7VgQiUZj7o03UgS6qX8nq Qwno9gx0ylH4qkXXiuFA11iJBKwZXHyFxP03xmAf5Db+HXiYY9Gsxsl0Led+zCeFhqNU UC4s58uD1+a48Mb1vEL11Rh4Uv+sTt1cIXzSlcCh7lPp/PsssjNz+rn7sWjMlccUNjVc 7HGEwtS0y6mjb8FlrlA4QWm2mqHIV4G6XRdLAQeNMhqXZoOuLflaDVPVzAOJziTxY7Yg +V6Q== X-Gm-Message-State: APjAAAVax+++yFTFsQ2AuOzlxgMq2lgUYi4PotRtQsje2CE38p64qCUC A4ayuau/BxVgVyaofsCXJv+i3Q== X-Google-Smtp-Source: APXvYqxofTBIjbpiccymicJb+TFhXC/Wg25mZw79v/mbL4+JIgE3MBVB1QvMEUvncZmiJjuqRgPKUA== X-Received: by 2002:adf:eac9:: with SMTP id o9mr27287657wrn.85.1554925849521; Wed, 10 Apr 2019 12:50:49 -0700 (PDT) Received: from cbtest28.netronome.com ([217.38.71.146]) by smtp.gmail.com with ESMTPSA id 4sm2288540wmg.12.2019.04.10.12.50.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Apr 2019 12:50:48 -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/RFC v2 bpf-next 09/19] bpf: introduce new bpf prog load flags "BPF_F_TEST_RND_HI32" Date: Wed, 10 Apr 2019 20:50:23 +0100 Message-Id: <1554925833-7333-10-git-send-email-jiong.wang@netronome.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1554925833-7333-1-git-send-email-jiong.wang@netronome.com> References: <1554925833-7333-1-git-send-email-jiong.wang@netronome.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@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 af1cbd9..f4214f8 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -256,6 +256,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 438199e..225867c 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 af1cbd9..f4214f8 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -256,6 +256,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: *