Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5527595pxb; Wed, 26 Jan 2022 14:11:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJwaXImh1gNIpK3rA/XVvl0JM8aI7H20Q37bJ08Wq1xTidHYO937JJ9/X4K6J6fXj/QaC8lA X-Received: by 2002:a17:906:58c8:: with SMTP id e8mr608584ejs.706.1643235101620; Wed, 26 Jan 2022 14:11:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643235101; cv=none; d=google.com; s=arc-20160816; b=JvxryjKfVaZfXOffbWkr0jbCPCrHfox2f1/36eCQwXdEB0YuoHI/48K7FQsMgAq6Rj D8tNXV9JDZVeHMQ55W32AhcAplIbPNnlF3V6Pqxe3WtziTYLZV5Bva4FBbWa5f7eNRyC 8pZEKrv3yvqZi4AVkfeRFPdJ3hDWErwNyYvdP8nF7i8KPzStvWulq88wCSAHQUNAQTjQ kgOWf4XVtElmdPqgYcJny5JZpuNSI6gFWdvngn5v9JfcC7KZ3TCj6n134oN55Bl2MUVd PL9l3kbWFcS4rBdEV1VaoxTdCXTachDtWcbIiHHtmF1Ibby6jd2eDcqJnORqRxzrZZ+a 3xjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=PfhZnL0BIYytNIACD0+wNWQ47gSosDAtf+9cgkj0ZVw=; b=LmP1Y0DqgC7X/sqBQJDm8biK5HaVxXWycLZh2Kmn64Y70a+8PSSMKZjXH12NIJBo2w hqrTT+DGUCX8qPqlUzQVphNgp8ILo1nIzLRTB5jV/gZ36ZF3Bx29H9PJ1CY8zfLqxcUE UNrX28VZIShMyjG+K4ndAcT8h7/ISSRBNuMRbBf72O693Bs31r5VAh876bUSOlNYDUGS uIrdaSZMUqP3koGcwTRcmHqhxPFf1ibqmBoMpaG3zx0oAqJlYf9Dv16E4c+7LJYO5W3r jzS/K3sWDVGECecCwqzLSjU1pg0e2QxqWV98UG00Y980+a3s3xmE+Snt7pIB3gIKJ0yz W+0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ioVG4xKb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sg37si287231ejc.314.2022.01.26.14.11.16; Wed, 26 Jan 2022 14:11:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ioVG4xKb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231997AbiAZPy7 (ORCPT + 99 others); Wed, 26 Jan 2022 10:54:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231177AbiAZPyy (ORCPT ); Wed, 26 Jan 2022 10:54:54 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD238C06161C for ; Wed, 26 Jan 2022 07:54:54 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6C7C6B81EFD for ; Wed, 26 Jan 2022 15:54:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80E80C340E3; Wed, 26 Jan 2022 15:54:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643212492; bh=IIHhUmLrk+ly/tOHaZfanJN3Jp4qrbBjymc58Is+O+0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ioVG4xKbhhEryA671lyFldKC1d7fBSzw12HShHDRfoQgKTGLt9H3CiRTzHuzJwKqS btHkF2EY/JvZhJd2qpGTtjFe5T3sRlVLWdlmHdrYUD1A962oEz82GC9OK3iI3mbnfA 7LdzLpF+1NJJGLxg+DZIaJHbmhVaI2+Y4qM6eKh3UOqWfJRY0+4/vD+wxmKh9pbVZu +j8mranfOUKpHdO6nHYuLWQY69v+jh62aAS84KI7vwVRzMz/F2nTtbxEmEeKItm9zn 1T2OdVWnRBq+vYaYMdY7DiY2Y8PuoDvYIAAPrqf+RtnSLI43xnA2yoimw1cbz7TzXi dVTTcRD1GbDIw== Date: Thu, 27 Jan 2022 00:54:47 +0900 From: Masami Hiramatsu To: Jeff Xie Cc: Steven Rostedt , mingo@redhat.com, Tom Zanussi , linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 0/4] trace: Introduce objtrace trigger to trace the kernel object Message-Id: <20220127005447.143a840e9b0f67d894b8c54a@kernel.org> In-Reply-To: References: <20220113013835.503285-1-xiehuan09@gmail.com> <20220118232448.891fbf550b50193e0155b59c@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jeff, On Wed, 19 Jan 2022 10:32:49 +0800 Jeff Xie wrote: > > > Note: when change to use the ftrace_test_recursion_trylock, all the functions > > > will call the copy_from_kernel_nofault, I don't know where this is the problem now, > > > maybe should fall back to the usage in v6. > > > > > > for example: > > > > > > cat-118 [000] ...1. 1.458998: __bio_add_page <-bio_add_page object:0xffff88811a12e9e8 value:0x0 > > > cat-118 [000] ...2. 1.458998: copy_from_kernel_nofault <-trace_object_events_call object:0xffff88811a12e9e8 value:0x1000 > > > cat-118 [000] ...2. 1.458998: copy_from_kernel_nofault_allowed <-copy_from_kernel_nofault object:0xffff88811a12e9e8 value:0x1000 > > > cat-118 [000] ...1. 1.458998: __rcu_read_lock <-xa_load object:0xffff88811a12e9e8 value:0x1000 > > > cat-118 [000] ...2. 1.458998: copy_from_kernel_nofault <-trace_object_events_call object:0xffff88811a12e9e8 value:0x1000 > > > cat-118 [000] ...2. 1.458998: copy_from_kernel_nofault_allowed <-copy_from_kernel_nofault object:0xffff88811a12e9e8 value:0x1000 > > > cat-118 [000] ...1. 1.458998: __rcu_read_unlock <-xa_load object:0xffff88811a12e9e8 value:0x1000 > > > cat-118 [000] ...3. 1.458998: copy_from_kernel_nofault <-trace_object_events_call object:0xffff88811a12e9e8 value:0x1000 > > > cat-118 [000] ...3. 1.458998: copy_from_kernel_nofault_allowed <-copy_from_kernel_nofault object:0xffff88811a12e9e8 value:0x1000 > > > .... > > > > Hmm, this is strange, but I got it is the expected behavior, since the > > ftrace_test_recursion_trylock() accepts one stage recursion for the > > first event in the interrupt as transition event. I think you should revert that change and back to your own per-cpu recursion flag instead of using ftrace_test_recursion_trylock(). Thank you, -- Masami Hiramatsu