Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4624074ybb; Tue, 14 Apr 2020 10:54:13 -0700 (PDT) X-Google-Smtp-Source: APiQypISePmTQDx7FS0BjJkzJd6697RnItaWWELTQ3IOpXqbyBivUtNKlKvtiSgplQodz72Ye1iJ X-Received: by 2002:aa7:dc17:: with SMTP id b23mr21237027edu.321.1586886853629; Tue, 14 Apr 2020 10:54:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586886853; cv=none; d=google.com; s=arc-20160816; b=IAZAMtOiPvLUCGVSz9ue5IP2lvNwCs9SZQhPruOUYhEx34YFg7juXk7W0c3KMhAAnN g+GfhhvaNTndcjrt6xJjLjJxHAyaR9/277B6hfCtK2LJZwo9eedMAhjBiqypVo1cJ5bP vx7zoDyVWIKVNwEbnwWtikVmdyWU0zszJj7SD3kEmC2fiAmypX4toqjyYaWz1tc6HXPk 25uYWYlzQ8rxfhuk29MmpmQbWrw23Xn3G3Cpo36tlbw8ngF1C7euYruFHVcCOdqh6rBG vk93+rdE6yzWaUG1cdrpyr3VCJFMweOjG3Gnet5HRiug/htkP9FnvOPk+dsY4L2NTRWF 3X4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=I9Qx7EH+5a+CF7i4XObXioQMfjcZ+IFHZLSfpOe38W4=; b=qnQW6hWPBlf6RI+7sa3Wzkv5zaZOhern99CiY1CcQltk8Nw+BjE/qnaWSyZp/UTUXu DHdAbZfQ8gWsr4NZ5mTG/G6IChujH6CJIuj8KqJ88VR8MaqX7C73PLWeLMHyxR/P4qT0 C+HqEPeveUMTjoKkBJgY62m0urgsr5UAPdBvD8WMCbheUkftd3hZRS3i7IiJ0D1JEXzI JnZ8OpmNMV0dxNpdcfvmbVB660C2/NBkXnMmV198EXbxfaT7A4mJNq8TXM+FOoaNeUeu BHs8LGpy6hZeGruC0CisSD42RaOx5+eD83gQx1Gsa2NpBEMixCYCpmVuGb3A+xr3JDT6 sj9Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k14si2520664ejg.168.2020.04.14.10.53.47; Tue, 14 Apr 2020 10:54:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for 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; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730899AbgDMPCN (ORCPT + 99 others); Mon, 13 Apr 2020 11:02:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:33174 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728537AbgDMPCL (ORCPT ); Mon, 13 Apr 2020 11:02:11 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 08E5A20656; Mon, 13 Apr 2020 15:02:09 +0000 (UTC) Date: Mon, 13 Apr 2020 11:02:07 -0400 From: Steven Rostedt To: Xiao Yang Cc: , , , Subject: Re: [PATCH] tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation Message-ID: <20200413110207.01a48591@gandalf.local.home> In-Reply-To: <20200413071252.13720-1-yangx.jy@cn.fujitsu.com> References: <20200413071252.13720-1-yangx.jy@cn.fujitsu.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Apr 2020 15:12:52 +0800 Xiao Yang wrote: > Traced event can trigger 'snapshot' operation(i.e. calls snapshot_trigger() > or snapshot_count_trigger()) when register_snapshot_trigger() has completed > registration but doesn't allocate spare buffer for 'snapshot' event trigger. > 'snapshot' operation always detects the lack of allocated buffer in the rare > case so make register_snapshot_trigger() allocate spare buffer first. > > trigger-snapshot.tc in kselftest reproduces the issue on slow vm: > ----------------------------------------------------------- > cat trace > ... > ftracetest-3028 [002] .... 236.784290: sched_process_fork: comm=ftracetest pid=3028 child_comm=ftracetest child_pid=3036 > <...>-2875 [003] .... 240.460335: tracing_snapshot_instance_cond: *** SNAPSHOT NOT ALLOCATED *** > <...>-2875 [003] .... 240.460338: tracing_snapshot_instance_cond: *** stopping trace here! *** > ----------------------------------------------------------- > > Signed-off-by: Xiao Yang > --- > kernel/trace/trace_events_trigger.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c > index dd34a1b46a86..00e54cdcef3e 100644 > --- a/kernel/trace/trace_events_trigger.c > +++ b/kernel/trace/trace_events_trigger.c > @@ -1088,9 +1088,13 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops, > struct event_trigger_data *data, > struct trace_event_file *file) > { > - int ret = register_trigger(glob, ops, data, file); > + int alloc_ret, ret; > > - if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) { > + alloc_ret = tracing_alloc_snapshot_instance(file->tr); > + > + ret = register_trigger(glob, ops, data, file); > + > + if (ret > 0 && alloc_ret != 0) { > unregister_trigger(glob, ops, data, file); > ret = 0; > } Why register if the allocation failed? Just switch the logic: int ret = tracing_alloc_snapshot_instance(file->tr); if (ret != 0) return 0; return register_trigger(glob, ops, data, file); -- Steve