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 E6765C433EF for ; Mon, 14 Feb 2022 20:57:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230171AbiBNU54 (ORCPT ); Mon, 14 Feb 2022 15:57:56 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:48296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229977AbiBNU5e (ORCPT ); Mon, 14 Feb 2022 15:57:34 -0500 Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5332613911C for ; Mon, 14 Feb 2022 12:56:58 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id k25so16635806qtp.4 for ; Mon, 14 Feb 2022 12:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ttJu1XMf1+hA+hrMQ5r00OCzrFkN94Y4YW3j0uNrxV8=; b=hr+TWd2YTvC14HH5KLVZE3+GCtF6eZvPPD6LASFw0DJGN9OgAZCjUR6WUWoVS69jSW clj8d86ROskMUqHEaPm3XQjwNDI3Rr91p0vT6W0xRLCGwXHAY5SxD8AhF0A+UC8ij/FT T4V46FpPWiYlBh/9OAZ9eRf1HztNX/WDBM+3w20JzYCZwoJg4+lKUstn2oxwFrSPl2me r2ey1rlgdh7vjxGQWvXEcfmKQ5Uehd0ZreduPnbsGVgzpRJCfFd3cQGyKLTpBc+ZbeAe Y545Xujo2QmmXI2Vz11AC8b39o3tVQJm4fRyt6gRfbxMzl8itRY34+gs5GuK4KjA7Sg9 SDvg== 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=ttJu1XMf1+hA+hrMQ5r00OCzrFkN94Y4YW3j0uNrxV8=; b=H8xQmxwll9THLuEwoSdanjdG0S5f89WWKhVsMwSwYZTHM85FAghWjWyqsqhmwtga3S fI294tjrN3kJz8gQqCMXWz4+fGOID9WRHpjw3ygHu8kgJe2iAOSJShdt4/cj73CgQdl1 d2Mpi1aDm0mBAG2JjfeA/rBP3yb2GIOyCRQYronQTW2jnyL8Ar3Q7IwV02iRuQjg17Wd lneqQi4aMJHubL0pU5bTsv05B46QRgKdu8qjo0TgBPxeorPzq3bCa0sbibL9U5PflWJ9 ge0PuQNbq7XBTUOYdSSMq7yJT6eUAIqfkp3rEpFKSnfHtk0BqO1/5h5peQI0MgvDtjhD ysrA== X-Gm-Message-State: AOAM530atCOLJFoq566wmYPeMsLBk/3hdfqaYxdhWCWRfvstrSmqChHV A6uosk+YyiK+QkeiiFVthB3KSX9pgDT+OKDPuWAolmUI6Tg= X-Google-Smtp-Source: ABdhPJwiPFE8fdGZixjazWuzi7yJKv+5h1ACgsQMcp2+YO1XcbXd+6bVa6c5pWYdoHLKobd3nqtKYGMm6a6IidIncik= X-Received: by 2002:ae9:ed96:: with SMTP id c144mr370649qkg.221.1644870221334; Mon, 14 Feb 2022 12:23:41 -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: Hao Luo Date: Mon, 14 Feb 2022 12:23:29 -0800 Message-ID: Subject: Re: [PATCH RFC bpf-next v2 5/5] selftests/bpf: test for pinning for cgroup_view link To: Alexei Starovoitov 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 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.