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 8D48CC433F5 for ; Mon, 14 Feb 2022 20:49:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229779AbiBNUts (ORCPT ); Mon, 14 Feb 2022 15:49:48 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:35424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229614AbiBNUtp (ORCPT ); Mon, 14 Feb 2022 15:49:45 -0500 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59E7215FC87 for ; Mon, 14 Feb 2022 12:49:29 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id o3so16589538qtm.12 for ; Mon, 14 Feb 2022 12:49:29 -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=HDLiuYUP5DHdmjW4f062r2zlI41NFhxRv09UtgBUw+M=; b=QnBu1cdZSNMZMwTUOhTAgwrDV0UDotuXjd+L9tGoRib5LiAOViseQ3Shth3I3/9cUX F9FE9WP/n9IXs5G/YdanGCNFX3mwzenNKyGas7OHzij+neOt+7N0L8gulZksssphH0JK ZdAH701JpydqzO4zSQ63RxEFI/i6gMAqnIMJnBkw252CYXQsB0CmiD9JEAKRqabXkDss C24cvW5+nsV74dkDMeh0PKiv6q73XtCwF3kNhQmHGY7iVbEX5fIf1tLZZzQ/qHEwjapy YPS22mz/ReXGyT+0yl9O+kILA0cSXtpXCAn5q4MdtEBUg/J2KAwutMzm1ZQ8iCW+2Fdu 29yQ== 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=HDLiuYUP5DHdmjW4f062r2zlI41NFhxRv09UtgBUw+M=; b=xUQ0smfRzCFJjqbxTxCsyblRW+6aoNqzyEUsCm/j6LRfcE5qqnp3TxHyL62Kn0JHqr ee+ZFz3SzDs3/ubM9KEDk3L1zmja0WJVceYMIPjdLO43jY8yoOuU87NMNVyjxrBtuj3i StqlateR6rf4zSeSGwYfChac5MEPc/iirnTI9dRrBwiitOlX8U7vtCsltLMPBrj40RmT nNwnLQj+a+ydehV/QqWndsGJzOFgJrU9W6fhQUQ6kkP5kKfD8NEsdpEB6M0i4InlKe+A kPbdW+KceWWVJJExfrYTBN52qgnq1dy4UA2LwwX3X1CyGWmc3/MnW7re/shicSXbhpTg KEAw== X-Gm-Message-State: AOAM532P/Aqab6ZDNslkH3dDQUZrVecgyWfGd8A2g2VYjmD+6S08Xs9b ANhTnmkS+f5aTq/6mJSMXCx3XQC6v39IYKktVJtdPYzvv7zS2w== X-Google-Smtp-Source: ABdhPJzbvpTWXVuIjS/XjHNa8littqTkjF6TQBikKhXHbgTCjjUteC4b/xejz1U2eG7DGGSoU8BB+NLCXOAU65/AcM4= X-Received: by 2002:a05:620a:470a:: with SMTP id bs10mr392145qkb.583.1644871152704; Mon, 14 Feb 2022 12:39:12 -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:39:01 -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 12:28 PM Alexei Starovoitov wrote: > > 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. No problem. I'll take a look at it. Thanks!