Message ID | 20230218105921.12ddb86f@gandalf.local.home |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp437353wrn; Sat, 18 Feb 2023 08:07:46 -0800 (PST) X-Google-Smtp-Source: AK7set+NDGuLKXdm2LAnEDGuxNgnA+Rus7abazO2o5JolrXaJ7uUnIe7xw6nQNJi0I+RYrskp0iD X-Received: by 2002:a17:902:e807:b0:19a:df6a:726f with SMTP id u7-20020a170902e80700b0019adf6a726fmr2154144plg.61.1676736466125; Sat, 18 Feb 2023 08:07:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676736466; cv=none; d=google.com; s=arc-20160816; b=ZC+1uJD7ckEGpQ/ZH5FbBUO0me1FCFrk9iFdSUsishM+1Ls4X8xC7wgajyx38GLQmg tivD02jdFT/H6XE5vFQnAXlhuCimD2owxcj50QY6jg0bg6omRE78BVTWAAZhRA9KSe0M y12EMhDkX7uvXdXgLv/xa3AIQxqKBEBIVVE3F1jYMXODYZQQ8FXaX0aZvT54wZv2J5OQ Rn2zmJTfJh2VC+l3FMPQnMoukO2Dm7smUSfMAHMmOQVPqlK8t8oQw40dYJ04AXwXx1Xy V37HmmlDANqGxube7QUv424fA1bEDaWOYWcGWSIgaUoBVY/dElb1R2CKZcwIu0yll+fL 2cNg== 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 :message-id:subject:cc:to:from:date; bh=zhWWQG0NEiBLp7Vt6BuiLcHaYtXnLmKd98TpEh+qMEI=; b=M55aiZd1bz5rYkVyyGRryqQn5p4AsMAPDQrp8IAQ1CBHvKDNrY868vJMYraZcvrTz+ R7ni6XfP+t25I8XYAbjIGiVfLFKA32IAg6crR2Y6XOfjiGXRP8G2tuFoRPBdIAwqzG81 DdsVTGvb7RErMwZFkze8tgZSpJYUgLjO3FC746NO9S/WyVF1R8T+85bP5vvBNPfqYLiE xzPgsRYc1YuUw6fGUTpp9Ur8n5+1nSOtTVjaKq3Bf0i/NLQ4m3OeHr/L+WmhC0+3iFSF oHusfbs5m2Qsde6UaobzIZbI+aoJJ0DOXcqX+I2nH3cvPYVtOm2P4WlnehT1v9qjCZ5n eQsQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l14-20020a170903244e00b001990cb9ce7asi3791424pls.204.2023.02.18.08.07.32; Sat, 18 Feb 2023 08:07:46 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229678AbjBRP73 (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Sat, 18 Feb 2023 10:59:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229585AbjBRP71 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 18 Feb 2023 10:59:27 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42A4217CDB; Sat, 18 Feb 2023 07:59:25 -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 C60E860B99; Sat, 18 Feb 2023 15:59:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85878C433D2; Sat, 18 Feb 2023 15:59:23 +0000 (UTC) Date: Sat, 18 Feb 2023 10:59:21 -0500 From: Steven Rostedt <rostedt@goodmis.org> To: LKML <linux-kernel@vger.kernel.org>, Linux Trace Kernel <linux-trace-kernel@vger.kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org>, Tom Zanussi <zanussi@kernel.org>, ionut_n2001@yahoo.com Subject: [PATCH] tracing: Check for NULL field_name in __synth_event_add_val() Message-ID: <20230218105921.12ddb86f@gandalf.local.home> 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 X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758185616639121352?= X-GMAIL-MSGID: =?utf-8?q?1758185616639121352?= |
Series |
tracing: Check for NULL field_name in __synth_event_add_val()
|
|
Commit Message
Steven Rostedt
Feb. 18, 2023, 3:59 p.m. UTC
From: "Steven Rostedt (Google)" <rostedt@goodmis.org> It is possible that the field_name passed into __synth_event_add_val() can be NULL with the trace_state set to add_name (possibly set from a previous call), in which case it needs to be checked. Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217053 Fixes: 8dcc53ad956d2 ("tracing: Add synth_event_trace() and related functions") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> --- Tom, can you review this. Is there a legitimate case where you can have a previous call set "add_name" but the next call not require it? This patch assumes that it can't. kernel/trace/trace_events_synth.c | 4 ++++ 1 file changed, 4 insertions(+)
Comments
Hi Steve, On Sat, 2023-02-18 at 10:59 -0500, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" <rostedt@goodmis.org> > > It is possible that the field_name passed into > __synth_event_add_val() can > be NULL with the trace_state set to add_name (possibly set from a > previous > call), in which case it needs to be checked. Hmm, I don't think this really is possible, see below... > > Cc: stable@vger.kernel.org > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217053 > Fixes: 8dcc53ad956d2 ("tracing: Add synth_event_trace() and related > functions") > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > --- > > Tom, can you review this. Is there a legitimate case where you can > have a > previous call set "add_name" but the next call not require it? This > patch > assumes that it can't. > No, because this code just above it makes sure you can't mix add_name with add_next. Once add_name is set it will return -EINVAL if field_name is ever null after that, and add_name will never be changed once set: /* can't mix add_next_synth_val() with add_synth_val() */ if (field_name) { if (trace_state->add_next) { ret = -EINVAL; goto out; } trace_state->add_name = true; } else { if (trace_state->add_name) { ret = -EINVAL; goto out; } trace_state->add_next = true; } > kernel/trace/trace_events_synth.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/kernel/trace/trace_events_synth.c > b/kernel/trace/trace_events_synth.c > index 70bddb25d9c0..fa28c1da06d2 100644 > --- a/kernel/trace/trace_events_synth.c > +++ b/kernel/trace/trace_events_synth.c > @@ -1982,6 +1982,10 @@ static int __synth_event_add_val(const char > *field_name, u64 val, > > event = trace_state->event; > if (trace_state->add_name) { > + if (!field_name) { > + ret = -EINVAL; > + goto out; > + } So if add_name is set here, it must also mean that field_name can't be null, because of the above. > for (i = 0; i < event->n_fields; i++) { > field = event->fields[i]; > if (strcmp(field->name, field_name) == 0) And if field_name can't be null, then I don't see how this strcmp could fail due to a null field_name. So I don't see the need for this patch. The bugzilla shows a compiler warning when using -Wnonnull - could this just be a spurious gcc warning? Tom
On Sun, 19 Feb 2023 15:46:24 -0600 Tom Zanussi <zanussi@kernel.org> wrote: > No, because this code just above it makes sure you can't mix add_name > with add_next. Once add_name is set it will return -EINVAL if > field_name is ever null after that, and add_name will never be changed > once set: > > /* can't mix add_next_synth_val() with add_synth_val() */ > if (field_name) { > if (trace_state->add_next) { > ret = -EINVAL; > goto out; > } > trace_state->add_name = true; > } else { > if (trace_state->add_name) { > ret = -EINVAL; > goto out; > } > trace_state->add_next = true; > } > > > > kernel/trace/trace_events_synth.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/kernel/trace/trace_events_synth.c > > b/kernel/trace/trace_events_synth.c > > index 70bddb25d9c0..fa28c1da06d2 100644 > > --- a/kernel/trace/trace_events_synth.c > > +++ b/kernel/trace/trace_events_synth.c > > @@ -1982,6 +1982,10 @@ static int __synth_event_add_val(const char > > *field_name, u64 val, > > > > event = trace_state->event; > > if (trace_state->add_name) { > > + if (!field_name) { > > + ret = -EINVAL; > > + goto out; > > + } > > So if add_name is set here, it must also mean that field_name can't be > null, because of the above. > > > for (i = 0; i < event->n_fields; i++) { > > field = event->fields[i]; > > if (strcmp(field->name, field_name) == 0) > > And if field_name can't be null, then I don't see how this strcmp could > fail due to a null field_name. > > So I don't see the need for this patch. The bugzilla shows a compiler > warning when using -Wnonnull - could this just be a spurious gcc > warning? Thanks, I should have caught that (I was even looking for that logic, but still missed it). That's what I get for writing patches while jet-lagged :-p -- Steve
diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c index 70bddb25d9c0..fa28c1da06d2 100644 --- a/kernel/trace/trace_events_synth.c +++ b/kernel/trace/trace_events_synth.c @@ -1982,6 +1982,10 @@ static int __synth_event_add_val(const char *field_name, u64 val, event = trace_state->event; if (trace_state->add_name) { + if (!field_name) { + ret = -EINVAL; + goto out; + } for (i = 0; i < event->n_fields; i++) { field = event->fields[i]; if (strcmp(field->name, field_name) == 0)