From patchwork Wed Oct 19 08:24:09 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 4608 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp211150wrs; Wed, 19 Oct 2022 02:04:13 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6ywXlZlCrySZnEtl04Ip/lupPb4hBmR0I6f6XY/2zNS5s+UUk99g6Vd0opIFMIbi7qqAv4 X-Received: by 2002:a65:554b:0:b0:46a:f646:6374 with SMTP id t11-20020a65554b000000b0046af6466374mr6474030pgr.356.1666170252806; Wed, 19 Oct 2022 02:04:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666170252; cv=none; d=google.com; s=arc-20160816; b=YAdtZu1JgiPk2jPE9H9jYGeIsDp+IA3PVIyPHNHKb3Ny5C1cYwan0Ji4un887zYfO2 I4O9SwezUFXddNZviXU0R679MD4n1TSl/7gaPHu4GtN/4AqDAREVLWgErVuA/Er2cjUP /TrCsOV824kQm+WLv8l6zbGVMbDCbpS1d2BIxs4x4VTxKN1XaEFEkM3tvIkdQWNB221x WzI1sbbvDru2Fz+u+QV5gSN7DwtCt5sQ/rRwixjvlsnhGH+sDDivQ9kzmx0CREq/jU8E 3AccgKpe9oAGgFincmLXw0rUWyKFi8XKJX9WUtSzk1XByC0Q6E4eVIfO4UnWfg56PMcQ 6NYw== 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=xNHvsnvzzFFda9e6shvSkOg3EVdeXXBgXmEyQAx6TDMJByKbwExDGcP6UmllzzISF3 JZO5wNYZlNXv5PH0y2xLjmbGjFSnDtQLt73SCPjLgyoec0A+oraKMeKEadXTBszaEopC HmFM4ttQmzdBM36r02Sfs3DUZkgJqsvhxxCH77llCIpDMo6hG9jNpkqMO4CmPAieS+TW HJpwJ3hzbtLyNn2YHkB61h61TxPaoNfAeAz0kJy3saSSXTrv8AWjj3z1K6QN6cdEEmLe 5UAI5k3u6Nuuqrksl4XpQgS7VdX4vsX2skp4xk9UzvKX5Me09CSsKAtte1UERInmOzEa 4RGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Fs7XpqUd; 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 63-20020a630242000000b0046107c067c7si17529762pgc.822.2022.10.19.02.03.46; Wed, 19 Oct 2022 02:04: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=Fs7XpqUd; 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 S230124AbiJSIwQ (ORCPT + 99 others); Wed, 19 Oct 2022 04:52:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232105AbiJSIuW (ORCPT ); Wed, 19 Oct 2022 04:50:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6B4324BD9; Wed, 19 Oct 2022 01:49:12 -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 dfw.source.kernel.org (Postfix) with ESMTPS id CF4E26181D; Wed, 19 Oct 2022 08:45:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2846C433D6; Wed, 19 Oct 2022 08:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666169110; bh=c9ygUptf6V7bC9GOUoGrIQJL+pvol/TW/5HDxSDa1cA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fs7XpqUdbwe+Wb0k+Ar+08aNfsZQ7RSQfK26XXO0L02kqlQCMSqP5kStpJiA7rGId E0AayaDBgpChb+4eVdJL5IodaDww0jWswU/kJLCAovBPD4PAeMrlNdBOEhE52G+qqJ v9nq72HCYoahMs3+SJDd3yXF6EVHbSAEiYbctOYc= 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 6.0 162/862] tracing: Do not free snapshot if tracer is on cmdline Date: Wed, 19 Oct 2022 10:24:09 +0200 Message-Id: <20221019083257.127954013@linuxfoundation.org> X-Mailer: git-send-email 2.38.0 In-Reply-To: <20221019083249.951566199@linuxfoundation.org> References: <20221019083249.951566199@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.4 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?1747106138828918797?= X-GMAIL-MSGID: =?utf-8?q?1747106138828918797?= 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) {