Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1494182pxm; Thu, 3 Mar 2022 19:52:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJxl+y4zmStIHKZMGPnWi3L3j3g1++qjTMQ01dUbxkjRixNI4w9J54+lNaahNpMju+AWjaX/ X-Received: by 2002:a17:906:3a04:b0:6d0:8d78:2758 with SMTP id z4-20020a1709063a0400b006d08d782758mr29761655eje.685.1646365945589; Thu, 03 Mar 2022 19:52:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646365945; cv=none; d=google.com; s=arc-20160816; b=lRsjeGuNtY8U3xTHxz8dM80kEb6fXPUWFhhDrtLFThggkuVfDQFRB65sDuFNbiLzxX XE6uUFaHP2rs6Ov6mdJSuvIyuT6mrS1WKOZjnz70IhZb5ESrXGiMW/8PfD3K2w6rTs4J 5Bp5r9iBAeX7Mb2MGsoiXHsQ0z8aVib71wNVr8nwMGgdnTMA2pBW8atbua1Qbte27pb2 wT5fmeBhfraue11VcMv6BfB4E3fK3QOAIVD9zx5YrlSuW4y8KX2K2GEUi0rYjeEBEqwv RnE5/dvI7pArV8QXegQ8OEqoEtfaubCGPrkhMZVKF7b7wACkSgKj5O10bBnj9Wanf4Sp PmVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=OQRGmRac3HoqPUI4eVx9DWNAF0av56DUKyJ6WrJqlvc=; b=ykO9mC/POvAEspKkKIEunMp7TI6pX8q+vYXEK2QPr9Ybp1t6Ir25I5/MQYFEhjz+VM VNgnbvyvCO2PtdteoSuGyiRKT5pMQCtl7aVUJ5OVjuhHffS45aw5XDJmkntMfhVIbdkx jQnYs6I3aqhwn3oZ4oSd7X64x0Iqd49hPO2igOyOyv/yIGUtUqPk9RRVM1qnZIXVHgpL 6pBKmRbQjyO0zR+M+8OrhXLcnUaH5EhgBQvueEmyA64JcvrI0L+/y1CXF+tAA2scW4Ja 8ZRdFHpnJEGOv3je7jGuzbRJXIFIviYazq+hWzON3J7vsJI6KhBZ+7ofOCPOVBmUH8U0 D7Nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=tHE27GKz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j8-20020a1709062a0800b006d0b4d921a2si2362515eje.60.2022.03.03.19.52.03; Thu, 03 Mar 2022 19:52:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=tHE27GKz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233851AbiCCTpF (ORCPT + 99 others); Thu, 3 Mar 2022 14:45:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233645AbiCCToq (ORCPT ); Thu, 3 Mar 2022 14:44:46 -0500 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF78217CC75 for ; Thu, 3 Mar 2022 11:43:58 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id c7so4755782qka.7 for ; Thu, 03 Mar 2022 11:43: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=OQRGmRac3HoqPUI4eVx9DWNAF0av56DUKyJ6WrJqlvc=; b=tHE27GKzaq8/s+SrNHsu2bVFELPKQrOGq2k5ap+pGfutc6xtgH36rG6YuqRTucIHTQ zW3leSl9K+3AyvBQnkvwWJcgbEY3SnimmpAGO36MSJAKoJ/a+P9rSv+e4GGsMR6cbs8j sy9R+Dv/L7ytx2sLRr1pRTp8l+9JjwKjS6fUQaHfYd9LUn+vOpWabF8P3tyDmeB2t9tg Cq/5H5s+EvhA2DJjCwYrwoHk4WZUk5JLI9G1lVC8YZ5ILi6pK0q+EojgVohg1UaEFr0N da3mxve4ghOjCUor36+x0betMRDiuCJJ0Vq3JPeDIwaoTouRIEc+RiMV/GbtRcfEf3Eb DuPQ== 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=OQRGmRac3HoqPUI4eVx9DWNAF0av56DUKyJ6WrJqlvc=; b=sgk+NkqHGka0b2QObZpDOdb1C/7nKLLQiJ6IOK1Oq9EX7YSWgmUO+fbGjH7vjm7cif X1VGZN3U9Vh7Y6+vWjv0sssNk9Sj/eu6O01kUkr+ikVyoPpreKYgqjZzIVeDoZl7Uehu P6diRogdVTPCGkIK3bqJ2KXcMOkkUuTQ1OCkaUI2BSWKpQVb+DoM+4B72MeztFZHqd0P Q/5KlV8pOUHelfuka21NAqg97MKgCQ9+6PQ3RCKcZQfRlQPG2e/rUMQP7SpXgXsUfs7s mwnQAT13lJm+m+RcvHpPhBSBWx4A5x/+2J2vFR79Xgm/Wa9hkzzmBfJ5XBZmK1PXaouc O3pA== X-Gm-Message-State: AOAM5311l/2gRiMRknBQvqTA+BlcBVVfczpD+C1eHZ3RuVnsTRr3n9ez pu8ShH/qUA0xkPEx2bNqGB+ORGGXH8cCFzdcM343G/eZH8o= X-Received: by 2002:ae9:c10c:0:b0:663:2047:2eed with SMTP id z12-20020ae9c10c000000b0066320472eedmr480140qki.221.1646336637693; Thu, 03 Mar 2022 11:43:57 -0800 (PST) MIME-Version: 1.0 References: <20220225234339.2386398-1-haoluo@google.com> <20220225234339.2386398-5-haoluo@google.com> <93c3fc30-ad38-96fa-cf8e-20e55b267a3b@fb.com> In-Reply-To: From: Hao Luo Date: Thu, 3 Mar 2022 11:43:46 -0800 Message-ID: Subject: Re: [PATCH bpf-next v1 4/9] bpf: Introduce sleepable tracepoints To: Alexei Starovoitov Cc: Yonghong Song , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , KP Singh , Shakeel Butt , Joe Burton , Tejun Heo , Josh Don , Stanislav Fomichev , bpf , LKML Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-18.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 2, 2022 at 6:29 PM Alexei Starovoitov wrote: > > On Wed, Mar 2, 2022 at 5:09 PM Yonghong Song wrote: > > > > > > > > On 3/2/22 1:30 PM, Alexei Starovoitov wrote: > > > On Wed, Mar 2, 2022 at 1:23 PM Yonghong Song wrote: > > >> > > >> > > >> > > >> On 2/25/22 3:43 PM, Hao Luo wrote: > > >>> Add a new type of bpf tracepoints: sleepable tracepoints, which allows > > >>> the handler to make calls that may sleep. With sleepable tracepoints, a > > >>> set of syscall helpers (which may sleep) may also be called from > > >>> sleepable tracepoints. > > >> > > >> There are some old discussions on sleepable tracepoints, maybe > > >> worthwhile to take a look. > > >> > > >> https://lore.kernel.org/bpf/20210218222125.46565-5-mjeanson@efficios.com/T/ > > > > > > Right. It's very much related, but obsolete too. > > > We don't need any of that for sleeptable _raw_ tps. > > > I prefer to stay with "sleepable" name as well to > > > match the rest of the bpf sleepable code. > > > In all cases it's faultable. > > > > sounds good to me. Agree that for the bpf user case, Hao's > > implementation should be enough. > > Just remembered that we can also do trivial noinline __weak > nop function and mark it sleepable on the verifier side. > That's what we were planning to do to trace map update/delete ops > in Joe Burton's series. > Then we don't need to extend tp infra. > I'm fine whichever way. I see pros and cons in both options. Joe is also cc'ed in this patchset, I will sync up with him on the status of trace map work. Alexei, do we have potentially other variants of tp? We can make the current u16 sleepable a flag, so we can reuse this flag later when we have another type of tracepoints.