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=-3.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 DBA3BC433E0 for ; Tue, 16 Jun 2020 23:14:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AF66D207D3 for ; Tue, 16 Jun 2020 23:14:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OYjapKLa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725894AbgFPXOx (ORCPT ); Tue, 16 Jun 2020 19:14:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725849AbgFPXOv (ORCPT ); Tue, 16 Jun 2020 19:14:51 -0400 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8944C061573; Tue, 16 Jun 2020 16:14:51 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id d27so142765qtg.4; Tue, 16 Jun 2020 16:14:51 -0700 (PDT) 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=FbiG8uOfUL3pcz3BrmR6AwaddBM4+rmGpkdSVNLXbeE=; b=OYjapKLa8ZOFqLAQEAeUiDygXF+v1qJrCEHcOuS+aqSMVbiXh+74oW6gEp3OVAXAvY 3tm/XDyz4Orjfz4selMkLJhuXRbZ4SDBESHqKRyx9yxiyue6c4+C1jcrKxDca+Q0MJ2A DXUYZZAm/aH0t5Z1pygF3Lw4veL+WV6Aq1y2L3bX9pIx+F26loMld3lwZKL3QT5mCXWV Ja6gch0f36EInADcgBWBq4D3RMVss3gEaY0v5dUqnFdicKK522HX+5ywQe35Gmhh/BQ1 XyyzC7pxPYfBMBd9VAgBrsM9vZU140DuNtR3nqXO0likhz7Ji2ndr0VsKYX0dgm80ndo oZoA== 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=FbiG8uOfUL3pcz3BrmR6AwaddBM4+rmGpkdSVNLXbeE=; b=Fey2pRZlCpNzididjFVQL/O+fmtjh3D8B7eY2kX640V+/nOmCOUTOV/ReF3k0x8tT1 RoG+ONkU9zJf8aYnkdnMyvbAt3lc2hXiXc6TOLPfrFO8nDrVg8EM3XYhK2xRsxQnu3bC 4oXf1Mhz81rfouBpAPdLqIhpnZnx0XiiIZwg72NYbOZPzh2iKdKEYB1C7z7fTZslSdun 6fvGNXpMasV14mHZfReGh2r8pUkqctYpdxjNs8QqkbIPcFRHSz9Cb/qZ34Eiv6t3vsa0 YZJRvJmRC+0QPNBJkDZiuIWJgiYGkbOctvaOosCHcEJ/QbX0GkLzD4RHYOGWlyJKe73h 6Cqw== X-Gm-Message-State: AOAM530/V05q41e9OemFJcWv3FpF9jIQvmXMX6hvvlzIaCad3J9EplBM KKvC8uYJhoFP+ONx8vsCwG6N9oHKvPQ1gd6Ts1lmbZLS X-Google-Smtp-Source: ABdhPJxrW+bklmB57nZtcY1/zFwiLBeDVioV36nk+xL+kE//Qo3J1vZtlUSW9Zl+3vfkUg+gP01DSbLz0olFT8PyFgM= X-Received: by 2002:ac8:2dc3:: with SMTP id q3mr23294237qta.141.1592349290860; Tue, 16 Jun 2020 16:14:50 -0700 (PDT) MIME-Version: 1.0 References: <20200616050432.1902042-1-andriin@fb.com> <20200616050432.1902042-2-andriin@fb.com> <5fed920d-aeb6-c8de-18c0-7c046bbfb242@iogearbox.net> In-Reply-To: From: Andrii Nakryiko Date: Tue, 16 Jun 2020 16:14:39 -0700 Message-ID: Subject: Re: [PATCH bpf 2/2] selftests/bpf: add variable-length data concatenation pattern test To: Daniel Borkmann Cc: Andrii Nakryiko , bpf , Networking , Alexei Starovoitov , Kernel Team , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, Jun 16, 2020 at 3:23 PM Daniel Borkmann wrote: > > On 6/16/20 11:27 PM, Andrii Nakryiko wrote: > > On Tue, Jun 16, 2020 at 1:21 PM Daniel Borkmann wrote: > >> On 6/16/20 7:04 AM, Andrii Nakryiko wrote: > >>> Add selftest that validates variable-length data reading and concatentation > >>> with one big shared data array. This is a common pattern in production use for > >>> monitoring and tracing applications, that potentially can read a lot of data, > >>> but usually reads much less. Such pattern allows to determine precisely what > >>> amount of data needs to be sent over perfbuf/ringbuf and maximize efficiency. > >>> > >>> This is the first BPF selftest that at all looks at and tests > >>> bpf_probe_read_str()-like helper's return value, closing a major gap in BPF > >>> testing. It surfaced the problem with bpf_probe_read_kernel_str() returning > >>> 0 on success, instead of amount of bytes successfully read. > >>> > >>> Signed-off-by: Andrii Nakryiko > >> > >> Fix looks good, but I'm seeing an issue in the selftest on my side. With latest > >> Clang/LLVM I'm getting: > >> > >> # ./test_progs -t varlen > >> #86 varlen:OK > >> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED > >> > >> All good, however, the test_progs-no_alu32 fails for me with: > > > > Yeah, same here. It's due to Clang emitting unnecessary bit shifts > > because bpf_probe_read_kernel_str() is defined as returning 32-bit > > int. I have a patch ready locally, just waiting for bpf-next to open, > > which switches those helpers to return long, which auto-matically > > fixes this test. > > > > If it's not a problem, I'd just wait for that patch to go into > > bpf-next. If not, I can sprinkle bits of assembly magic around to > > force the kernel to do those bitshifts earlier. But I figured having > > test_progs-no_alu32 failing one selftest temporarily wasn't too bad. > > Given {net,bpf}-next will open up soon, another option could be to take in the fix > itself to bpf and selftest would be submitted together with your other improvement; > any objections? > Yeah, no objections. > Thanks, > Daniel