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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A2C1ECAAD4 for ; Tue, 30 Aug 2022 01:51:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229880AbiH3BvW (ORCPT ); Mon, 29 Aug 2022 21:51:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229864AbiH3BvT (ORCPT ); Mon, 29 Aug 2022 21:51:19 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8456AA6C1F for ; Mon, 29 Aug 2022 18:51:18 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id e20so12233778wri.13 for ; Mon, 29 Aug 2022 18:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=Q05G2zuncPpN5tmYJ7jQG6d9qUvvJiUejd0roDcqj9E=; b=tGK6VqsYBvmH9ycBcWO3t19n1kN5o7R6OtufsNYS+w5914lw3Hg2S+SaONPfMz+Wnu 157LkgyFDSvMI1WBIoeZ6yw29Sk7Cy/3ks74pnhx2aABrV1SYr9wr0LJtZ8J+Rff+qwA /JhXcOv3L930UF3Hoa15NUIzWJ4OKhF8EYaOjbt0gmYvH6pJzJ/ieEMqarhFxbXeQ8zQ s3uPCzIVpfknRBIKEA798acz/vRRqaz0HamIW5VmS9lYEY3vt8nPwuyAlG1kSr16lC9P 1NcyoS1H3VRmKyHBWqqQ0iDhy3WSRlZ9sEE5pmFYj5FzvXpP/G74phCUbK5yMVkBtk1f XusQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Q05G2zuncPpN5tmYJ7jQG6d9qUvvJiUejd0roDcqj9E=; b=G4/sMjH9iDXptdeLAYNvao7i8340jjknlt95vrJFG9Kn3j8YE8jqD/aGeK7ey4RfLD 9s6tRmZN4AkQ0vit9JDsO6lTtkRFr0mwNa4QEQbVH9ENadQuIjQBqPhcZvaPs3HYktSm U5Sl+9I3GECpnqCcjM/yazE8yPiOIDinCEqFS4DOg6UFNznBtL2tqWC1ceAXKuYUqeQR E1kkoRkR/nLMP4Bp/akbOUSz9gVN7rbnoDyIsFbe+P+aDqwFxSTVTQkWZIS2HVR+Hb3i bYdIrX2mPaYP9KdoOk+ImKkQdtmbVRdy71H/U7/ZAfrVdd65CJIcJVMxvzUsAGjWumO1 xJEg== X-Gm-Message-State: ACgBeo3B1usBAUf8ze68rwRQdE6+5MO6kmB66WMyMCqRbUT3fe3sH0vV Agn5DEXjg1I7bGBaHniaJobt0lK/c/WsYsseL0lIKw== X-Google-Smtp-Source: AA6agR5mXJrEV26XyK5LWMzqktTezuEYvByr6z1rzvf5kOhfA/GgHQlLShc9Oct06+8XRM37AJOQBV0ySnXwbNBjqjk= X-Received: by 2002:a5d:6609:0:b0:226:ced9:be58 with SMTP id n9-20020a5d6609000000b00226ced9be58mr7252461wru.80.1661824276689; Mon, 29 Aug 2022 18:51:16 -0700 (PDT) MIME-Version: 1.0 References: <20220826230639.1249436-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Mon, 29 Aug 2022 18:50:40 -0700 Message-ID: Subject: Re: [PATCH] selftests/bpf: simplify cgroup_hierarchical_stats selftest To: Hao Luo Cc: Andrii Nakryiko , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Mykola Lysenko , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Jiri Olsa , bpf , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 29, 2022 at 6:42 PM Hao Luo wrote: > > On Mon, Aug 29, 2022 at 6:07 PM Yosry Ahmed wrote: > > > > On Mon, Aug 29, 2022 at 3:15 PM Yosry Ahmed wrote: > > > > > > On Mon, Aug 29, 2022 at 1:08 PM Hao Luo wrote: > > > > > > > > On Fri, Aug 26, 2022 at 4:06 PM Yosry Ahmed wrote: > > > > > > [...] > > > > > > > > > > -SEC("tp_btf/mm_vmscan_memcg_reclaim_begin") > > > > > -int BPF_PROG(vmscan_start, int order, gfp_t gfp_flags) > > > > > +SEC("fentry/cgroup_attach_task") > > > > > > > > Can we select an attachpoint that is more stable? It seems > > > > 'cgroup_attach_task' is an internal helper function in cgroup, and its > > > > signature can change. I'd prefer using those commonly used tracepoints > > > > and EXPORT'ed functions. IMHO their interfaces are more stable. > > > > > > > > > > Will try to find a more stable attach point. Thanks! > > > > Hey Hao, > > > > I couldn't find any suitable stable attach points under kernel/cgroup. > > Most tracepoints are created using TRACE_CGROUP_PATH which only > > invokes the tracepoint if the trace event is enabled, which I assume > > is not something we can rely on. Otherwise, there is only > > Can we explicitly enable the cgroup_attach_task event, just for this > test? If it's not easy, I am fine with using fentry. I see a couple of tests that read from /sys/kernel/debug/tracing, but they are mostly reading event ids, I don't see any tests enabling or disabling a tracing event, so I am not sure if that's an accepted pattern. Also I am not sure if we can rely on tracefs being in that path. Andrii, is this considered acceptable? > > > trace_cgroup_setup_root() and trace_cgroup_destroy_root() which are > > irrelevant here. A lot of EXPORT'ed functions are not called in the > > kernel, or cannot be invoked from userspace (the test) in a > > straightforward way. Even if they did, future changes to such code > > paths can also change in the future, so I don't think there is really > > a way to guarantee that future changes don't break the test. > > > > Let me know what you think. > >