From patchwork Sat Oct 22 07:20:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 7467 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1098944wrr; Sat, 22 Oct 2022 01:12:13 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5qhwtXZG3p9UARHRGKwvIXaG+jf+6/HQT39ZQeu5xEKHqDjfsEinrvz/wyKgrYF5FhAa2K X-Received: by 2002:a63:1c43:0:b0:45e:1e2b:291d with SMTP id c3-20020a631c43000000b0045e1e2b291dmr19228385pgm.204.1666426332988; Sat, 22 Oct 2022 01:12:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666426332; cv=none; d=google.com; s=arc-20160816; b=zSFo0VqfjXdJJCc8DRUf2ps6aAZ481fkGlqR/iGdbTwfL4OHwxkK1r9MSzUTvBb6NJ altBjMtgp0ocjjqvRqIDnnwc2aTrehdoHYaR7OrfL5JLhCCDHPWdS21ImS5RX56Bdois VRYV1r1IKTBNv6qLwo0u1Vg+4SvRrI8KCUu9/cyQj/aIPPisuLGKtLucl0iuGGtAZtNp 0IAjkHgplRHBo891lZC+3sF7dGFvyXuK46YyvJWedCVuZYTG1mJMO0+j7mL2QthDcyTp RdxA71+OufUvKCIqRyw5q+GplSnQxzA8t22cITQL0Ia2NqQj7Mm/CVsOJkhnt+jLny7J bFiw== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=YhZfn5Z1PAb+XjaJBe5poyH99Jd6/5FRay5v1WwD3RY=; b=e1tpEtJ2NnnUCtKZz3PJLGxTK1pSWnSEgKljq6pZU80v0NT19ceOc1lNMc5Wlrk/sy UPPx1VEh/4XUKIfSIvG6XoosV0TYckxBrw1WRGuQYrhMhHJ1P3CLsgMZytuIs0Pgs1zR F0xq8FSX3HfL2UoNPbAay3dLqyZPQqvaACsbc1Sde5Ua9oIIIaQAfL+g/IFzIFEpQAAA NqeeuOuY87HDsVIYdVkwrp9DUM10xN8rLRh4NdPfzoxXjDFuC2O4ErxXDOPoxTx1A+XC bACskLyf2Fl1+tXEtunHR4DvU7U1+irvtwFnWAc/BfnP9EbidY5oWhTOJWWn0IRtBXGR bSVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=CR0hlwxN; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d16-20020a170903231000b0017f762e2dc6si32166880plh.613.2022.10.22.01.12.00; Sat, 22 Oct 2022 01:12:12 -0700 (PDT) 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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=CR0hlwxN; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233327AbiJVIL0 (ORCPT + 99 others); Sat, 22 Oct 2022 04:11:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233315AbiJVIJe (ORCPT ); Sat, 22 Oct 2022 04:09:34 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D8DC2CA7C9; Sat, 22 Oct 2022 00:54:08 -0700 (PDT) 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 37ADBB82E09; Sat, 22 Oct 2022 07:40:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8331DC433C1; Sat, 22 Oct 2022 07:40:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666424447; bh=c9ygUptf6V7bC9GOUoGrIQJL+pvol/TW/5HDxSDa1cA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CR0hlwxNVkUO+Ra9qEqBY5tYmb04RA2XuwglLJUbNgYOMEORUyJd72NxDHHRkGFra 69FSQ59Q1qor4Wt2k/HOoYfFC7wpcaxLBZAh8RVNEumQyaAteWTJtzaHeSl+vo8I35 4WmtGXb3u1i4GrUGk6webIAfJLNE2COWltlwLI5I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Masami Hiramatsu , Andrew Morton , Ross Zwisler , "Steven Rostedt (Google)" Subject: [PATCH 5.19 149/717] tracing: Do not free snapshot if tracer is on cmdline Date: Sat, 22 Oct 2022 09:20:28 +0200 Message-Id: <20221022072441.851172081@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221022072415.034382448@linuxfoundation.org> References: <20221022072415.034382448@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747374658503800791?= X-GMAIL-MSGID: =?utf-8?q?1747374658503800791?= From: Steven Rostedt (Google) commit a541a9559bb0a8ecc434de01d3e4826c32e8bb53 upstream. The ftrace_boot_snapshot and alloc_snapshot cmdline options allocate the snapshot buffer at boot up for use later. The ftrace_boot_snapshot in particular requires the snapshot to be allocated because it will take a snapshot at the end of boot up allowing to see the traces that happened during boot so that it's not lost when user space takes over. When a tracer is registered (started) there's a path that checks if it requires the snapshot buffer or not, and if it does not and it was allocated it will do a synchronization and free the snapshot buffer. This is only required if the previous tracer was using it for "max latency" snapshots, as it needs to make sure all max snapshots are complete before freeing. But this is only needed if the previous tracer was using the snapshot buffer for latency (like irqoff tracer and friends). But it does not make sense to free it, if the previous tracer was not using it, and the snapshot was allocated by the cmdline parameters. This basically takes away the point of allocating it in the first place! Note, the allocated snapshot worked fine for just trace events, but fails when a tracer is enabled on the cmdline. Further investigation, this goes back even further and it does not require a tracer on the cmdline to fail. Simply enable snapshots and then enable a tracer, and it will remove the snapshot. Link: https://lkml.kernel.org/r/20221005113757.041df7fe@gandalf.local.home Cc: Masami Hiramatsu Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: 45ad21ca5530 ("tracing: Have trace_array keep track if snapshot buffer is allocated") Reported-by: Ross Zwisler Tested-by: Ross Zwisler Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman --- kernel/trace/trace.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6428,12 +6428,12 @@ int tracing_set_tracer(struct trace_arra if (tr->current_trace->reset) tr->current_trace->reset(tr); +#ifdef CONFIG_TRACER_MAX_TRACE + had_max_tr = tr->current_trace->use_max_tr; + /* Current trace needs to be nop_trace before synchronize_rcu */ tr->current_trace = &nop_trace; -#ifdef CONFIG_TRACER_MAX_TRACE - had_max_tr = tr->allocated_snapshot; - if (had_max_tr && !t->use_max_tr) { /* * We need to make sure that the update_max_tr sees that @@ -6446,11 +6446,13 @@ int tracing_set_tracer(struct trace_arra free_snapshot(tr); } - if (t->use_max_tr && !had_max_tr) { + if (t->use_max_tr && !tr->allocated_snapshot) { ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) goto out; } +#else + tr->current_trace = &nop_trace; #endif if (t->init) {