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 0F8C1C4332F for ; Fri, 18 Nov 2022 02:17:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240892AbiKRCRi (ORCPT ); Thu, 17 Nov 2022 21:17:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240291AbiKRCRc (ORCPT ); Thu, 17 Nov 2022 21:17:32 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 845B787575; Thu, 17 Nov 2022 18:17:30 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 1C6FE6230C; Fri, 18 Nov 2022 02:17:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5ADB5C433C1; Fri, 18 Nov 2022 02:17:28 +0000 (UTC) Date: Thu, 17 Nov 2022 21:17:26 -0500 From: Steven Rostedt To: Rafael Mendonca Cc: Masami Hiramatsu , "Tzvetomir Stoyanov (VMware)" , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Tom Zanussi Subject: Re: [PATCH] tracing/eprobe: Update cond flag before enabling trigger Message-ID: <20221117211726.4bbbb96a@gandalf.local.home> In-Reply-To: <20221116192552.1066630-1-rafaelmendsr@gmail.com> References: <20221116192552.1066630-1-rafaelmendsr@gmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; 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 On Wed, 16 Nov 2022 16:25:51 -0300 Rafael Mendonca wrote: > That happens because enable_eprobe() will eventually trigger the > kmem/mm_page_alloc trace event: > > - enable_eprobe [trace_eprobe.c] > - trace_event_trigger_enable_disable [trace_events_trigger.c] > - trace_event_enable_disable [trace_events.c] > - __ftrace_event_enable_disable [trace_events.c] > - trace_buffered_event_enable [trace.c] > - alloc_pages_node [gfp.h] > ... > - __alloc_pages [page_alloc.c] > - trace_mm_page_alloc // eprobe event file without TRIGGER_COND bit set > > By the time kmem/mm_page_alloc trace event is hit, the eprobe event file > does not have the TRIGGER_COND flag set yet, which causes the eprobe's > trigger to be invoked (through the trace_trigger_soft_disabled() path) > without a trace record, causing a NULL pointer dereference when fetching > the event fields. > > Fix this by setting the cond flag beforehand when enabling the eprobe's > trigger. > > Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events") > Signed-off-by: Rafael Mendonca > --- Thanks for the report, but I'm worried that this isn't enough because of how memory ordering can happen on different architectures. That is, just because you switch the order of updates, doesn't mean that the architecture will honor it. I don't want to add memory barriers in the fast path, but instead we can simply check if rec is NULL in the handler. So basically: static void eprobe_trigger_func(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *rbe) { struct eprobe_data *edata = data->private_data; if (!rec) return; __eprobe_trace_func(edata, rec); } And this should be documented. -- Steve