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 914AEC77B7C for ; Sun, 21 May 2023 20:26:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231163AbjEUU0p (ORCPT ); Sun, 21 May 2023 16:26:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46508 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230083AbjEUU0n (ORCPT ); Sun, 21 May 2023 16:26:43 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A0ADDE; Sun, 21 May 2023 13:26:41 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-96fb45a5258so202725966b.2; Sun, 21 May 2023 13:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684700799; x=1687292799; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=X69f/eGnne5uw8yiXIr7+EFlS/jdrHMk5L4Y1wX1DGQ=; b=jnsY8z2hfPE31V+hrL/HzhhcAGpVZ6Mm21zRAWHOlkIBTGzfCaBM+h3RJct1KT13Qf M3qx5sdy6Dkr53cnZ9gVVAgU5awrQHDS6IA5Q1EdyGPZCL9EuyiLF/CPyru/DmBYGt+n ++9YboruM2OFupJ407QPbsSuQo2TYmJJOxiDkdfd12n+dS/RsjtT9/WJ/N4/62mvM1Gt HqGCf/m4XCIpHPv4qTpXZnwKP5j8zqzJP6gXB7RzcCMkKi9dH3+aAt7Ja3wHpIMznLPO xNqwQ8fGowGu3A3Krn3cuextzAYW3XidKaOh2papT5EgbNOZrjjsNnnt/YWlfzzzvQE4 LhSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684700799; x=1687292799; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X69f/eGnne5uw8yiXIr7+EFlS/jdrHMk5L4Y1wX1DGQ=; b=Ou/Rx+OxKXT5YzcS/rLOJ/JHh8YMBnd+pQalJS+uW5FFJ6FLg+tyFHThIdaCujG+94 tcNeuzNIZJbLdW9j+HqF3vUVhqDdfs0RxKoHfDo14Vys9EBPf4M9Xe8LdDkv6o+nburg bnsZrbpNelWS8AsmXoK2bO9tOsuU2VgSo1msANjl8eOWgrGRcmlEtIPuo7rFvDk3ufGX R5uQfBIPEbq5eQapxP3MNUBfyr74unwjxG6nTODRbL1IYUcSrC90q1O2eUOwcbR3qQnE NScVnvHGxR3Fn87+Gh3P6xhgaRpyTEAzoPfumB5XmKSRRqVLk3nlIbEYCweMtuEf8HFD G3jQ== X-Gm-Message-State: AC+VfDw1UMpOf6QnG88ISa3CwmMM8V1vUAoJ8OS9ZJT9+dugkAo/IQTW mHiP2tgBAoph6DOSxnkaYdI= X-Google-Smtp-Source: ACHHUZ74hjAZJLte5l7Qajhb8oZ9w/ViPSQhmPHkbC3tzZjyEiPOw2sJ6WzFVmLMROXwW5AUuRvdTA== X-Received: by 2002:a17:907:6d26:b0:957:2e48:5657 with SMTP id sa38-20020a1709076d2600b009572e485657mr7459511ejc.68.1684700799383; Sun, 21 May 2023 13:26:39 -0700 (PDT) Received: from krava ([83.240.61.63]) by smtp.gmail.com with ESMTPSA id t11-20020a17090616cb00b0094f1b8901e1sm2256648ejd.68.2023.05.21.13.26.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 May 2023 13:26:38 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Sun, 21 May 2023 22:26:37 +0200 To: Ze Gao Cc: Yonghong Song , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Hao Luo , John Fastabend , KP Singh , Martin KaFai Lau , Masami Hiramatsu , Song Liu , Stanislav Fomichev , Steven Rostedt , Yonghong Song , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, kafai@fb.com, kpsingh@chromium.org, netdev@vger.kernel.org, paulmck@kernel.org, songliubraving@fb.com, Ze Gao Subject: Re: Message-ID: References: <20220515203653.4039075-1-jolsa@kernel.org> <20230520094722.5393-1-zegao@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 21, 2023 at 11:10:16PM +0800, Ze Gao wrote: > > kprobe_multi/fprobe share the same set of attachments with fentry. > > Currently, fentry does not filter with !rcu_is_watching, maybe > > because this is an extreme corner case. Not sure whether it is > > worthwhile or not. > > Agreed, it's rare, especially after Peter's patches which push narrow > down rcu eqs regions > in the idle path and reduce the chance of any traceable functions > happening in between. > > However, from RCU's perspective, we ought to check if rcu_is_watching > theoretically > when there's a chance our code will run in the idle path and also we > need rcu to be alive, > And also we cannot simply make assumptions for any future changes in > the idle path. > You know, just like what was hit in the thread. > > > Maybe if you can give a concrete example (e.g., attachment point) > > with current code base to show what the issue you encountered and > > it will make it easier to judge whether adding !rcu_is_watching() > > is necessary or not. > > I can reproduce likely warnings on v6.1.18 where arch_cpu_idle is > traceable but not on the latest version > so far. But as I state above, in theory we need it. So here is a > gentle ping :) . hum, this change [1] added rcu_is_watching check to ftrace_test_recursion_trylock, which we use in fprobe_handler and is coming to fprobe_exit_handler in [2] I might be missing something, but it seems like we don't need another rcu_is_watching call on kprobe_multi level jirka [1] d099dbfd3306 cpuidle: tracing: Warn about !rcu_is_watching() [2] https://lore.kernel.org/bpf/20230517034510.15639-4-zegao@tencent.com/