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 E47CBC433EF for ; Mon, 14 Feb 2022 20:59:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229710AbiBNU7Z (ORCPT ); Mon, 14 Feb 2022 15:59:25 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:57182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229616AbiBNU7Y (ORCPT ); Mon, 14 Feb 2022 15:59:24 -0500 Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6EC8145E1C; Mon, 14 Feb 2022 12:59:10 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id x4so8500904oic.9; Mon, 14 Feb 2022 12:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c/bS6El9B0zRCiRKsjycXs0hnJXDV/WUGWitZwC9Ic4=; b=jILBRWKtzkWUzvcgS2TtBHr2FiKhc/8ebPSF7R/0nQgYxsyunQT0ay6z5V5NW6UJ9u lzzu6Rf5X0IX5cyZ8gwJ9qZ56Z7CAN3XeIkcULOv5Lonwc1t4Rvlk0AbXIsAcUXzpWYk L3cHi2ADLPm/hcYwXf997I+ZtmwbIpg2mfjXsrnj8ciiP9t+x69GDWT2QkBd4OR5f2PJ OIy3ISfH3csPXkqjTnYBNU8KOxtkTddTHMCmAtlYooeKJnSJQInOB5i5uUzdlCyI2Rsl 1iKmxz4rQUQUBV/M8OWE/AcfS5hQA6baq5iuWI+V0YYk7A3sPYU7OdV2CSCfLE/XfxuH TQbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c/bS6El9B0zRCiRKsjycXs0hnJXDV/WUGWitZwC9Ic4=; b=KM22bbmih8XMMzW9p9NCNaRsYmMe49yM1IeSF/OVtXimjUW7kWVOVz5mEifa9KR60P g9SK3yTHLdMVXPwo/wdj0KIGceg4/OlRzt5vZ3v7XXCGHl/DaQB2HhM8qjTQT4XkUPdE nENlyqmAd0cAw5gWULX5RwQi8nZiE+hwjwcQc9fo604EPh5+frXFcqu8DKPx/22zMiGG mbRa4w8htsYoUJgQVTaFlQQJ9ZWvvvUassJgAd7rUl0n4DspznTOviSdzAZ8l8u3MFLI NRhgfwfV3xf8jJ1nxqb8STOTCf+i57J2SwwOvCbW1Aa1qLhCj9XizKsmOu/fU4qyqlc0 yl5g== X-Gm-Message-State: AOAM530n59oR9Ej8au5G+bwKoYT+B3NCRokXoac3Y5MJ549kSG+ULfWV 1ovx1YESb0LY/BkUs0xl4zCz1fJrtS0Cah6FjNlt9ZGaiUw= X-Google-Smtp-Source: ABdhPJxiqJIdP0aB2Rv0HqfuOL9ch+awC64MhNT3LqkpB13Zakymd/P6lSMJzSyuq5i+p9qw+9RdnXfOMO7ngYC62Zg= X-Received: by 2002:a17:90b:1d84:b0:1b4:dc8e:2cc2 with SMTP id pf4-20020a17090b1d8400b001b4dc8e2cc2mr458721pjb.122.1644870485755; Mon, 14 Feb 2022 12:28:05 -0800 (PST) MIME-Version: 1.0 References: <20220201205534.1962784-1-haoluo@google.com> <20220201205534.1962784-6-haoluo@google.com> <20220203180414.blk6ou3ccmod2qck@ast-mbp.dhcp.thefacebook.com> In-Reply-To: From: Alexei Starovoitov Date: Mon, 14 Feb 2022 12:27:54 -0800 Message-ID: Subject: Re: [PATCH RFC bpf-next v2 5/5] selftests/bpf: test for pinning for cgroup_view link To: Hao Luo Cc: Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Shakeel Butt , Joe Burton , Stanislav Fomichev , bpf , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 14, 2022 at 12:23 PM Hao Luo wrote: > > On Mon, Feb 14, 2022 at 11:25 AM Alexei Starovoitov > wrote: > > > > On Mon, Feb 14, 2022 at 10:29 AM Hao Luo wrote: > > > Hi Alexei, > > > > > > Actually, I found this almost worked, except that the tracepoints > > > cgroup_mkdir and cgroup_rmdir are not sleepable. They are inside a > > > spinlock's critical section with irq off. I guess one solution is to > > > offload the sleepable part of the bpf prog into a thread context. We > > > may create a dedicated kernel thread or use workqueue for this. Do you > > > have any advice? > > > > Are you referring to spin_lock in TRACE_CGROUP_PATH > > that protects global trace_cgroup_path[] buffer? > > Yes, that's the spin_lock I am talking about. > > > That is fixable. > > Do you actually need the string path returned by cgroup_path() in bpf prog? > > Maybe prog can call cgroup_path() by itself when necessary. > > Parsing strings isn't great anyway. The bpf prog probably needs the last > > part of the dir only. So cgrp->kn->name would do it? > > The TRACE_CGROUP_PATH wasn't designed to be turned on 24/7. > > That global spin_lock is not great for production use. > > No need to delegate sleepable bpf to thread context. > > Let's refactor that tracepoint a bit. > > No, we don't need cgroup_path(). We are going to name the directories > by cgrp->kn->id. I can add a fast version for cgroup_xxx tracepoints, > which don't require the full path and can be turned on 24/7. Sounds good. We need a flag for tracepoints anyway to indicate which ones are sleepable. Probably similar to what we did for DEFINE_EVENT_WRITABLE.