From patchwork Wed Oct 19 08:23:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 5369 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp300178wrs; Wed, 19 Oct 2022 05:33:48 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Mn9+icPs6eR/daloMH6d4vLbKI10MMskxx3JjSmbRqn/KaTCKKLM7eb+DsbSnPAFdz/dF X-Received: by 2002:a17:902:eecc:b0:17f:624e:8af2 with SMTP id h12-20020a170902eecc00b0017f624e8af2mr8386669plb.152.1666182828052; Wed, 19 Oct 2022 05:33:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666182828; cv=none; d=google.com; s=arc-20160816; b=AjLEQPKd5/IsrKPXLvGNsz350LZD906y4wocHyX7oGeHGzau0nt4Q4MEsbA2utHX24 Vq9tkAapiO4l4O4cOPxERU5haq6P+A5DM7HSfbdE5hj5dwpz+sSM7gTGWzlGMpUaMDd+ SWIPILodHKgA/ds/Ox3WV3Xov+jl6puOq6f2/wnOLhIXKNmJ4+CnIFPNkDx9B5uhNiRb rWTD3mInYtL+8A9A0uVbODotTkUP72XaWyJ4WdmiY8oQHop2UHFDen7cslflxgBfoLNw DNpO7cGi/ETijPrZVHDkFdlzYkJ1Av6JqLFRZu2YtA9atKVNQgLXYgfEvjyY1dkVIH69 li2A== 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=0b9pI4mfr6IgPisSWcQHNT+roSjAl4h9Xkwnp9V5EbI=; b=o6QVtzdgsLt2JiaUp3Y8qkjiiZscAXj/HB9QKYmeoQxNpmkbO13Lqq+G2zimNkdDqF kvYXFAI8OmfxVv0GvcVM8DssVcbn2WrRPmWM19Ymgq6Gu1yhIekS3FkD44AsvZZsqg5i 8FemLNuz3QeEVs3YSA+QENAglfyv83sn1oGe2mQHMzOdM50Sc5lqehvv/STkmBrIIXV1 hSX8V5fndw3+dnBd6UrGodbJnT4kpltutw/z+Ff6Gn6eK1Hm/oJIb/HaBadb0FGiG80+ Vvekkl8TgBgPJodmyKjnL9yF0+N+Wimol6e0Od23kzifYyaC2nm5Zp1XUvGQa3huCYuV J8bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=TdPg5KRa; 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 o22-20020a63e356000000b00460c55062f0si19975256pgj.434.2022.10.19.05.33.33; Wed, 19 Oct 2022 05:33:48 -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=TdPg5KRa; 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 S231894AbiJSMVI (ORCPT + 99 others); Wed, 19 Oct 2022 08:21:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233203AbiJSMTj (ORCPT ); Wed, 19 Oct 2022 08:19:39 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A27D2F385; Wed, 19 Oct 2022 04:54:46 -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 3DAE3B82300; Wed, 19 Oct 2022 08:45:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51FDAC433D7; Wed, 19 Oct 2022 08:44:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666169101; bh=NugK2xmj4o35+zhTDpcBZCLwYbG8ZWgzp29Lg7nuEwM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TdPg5KRaHQtnAuDbtL9jKIwULVf1uA/5PLqb17eMKcnpUmn4WVXa0MKpGcOFqDmtP ml+Bg634veHiZv9kmOFhSPsDMM7xAGu8vzOGZcaeF+fOnHU7YUv5ldIcQDrqdLVkRZ Z5xnh9mvP7THpP1fpRT2Mbr96j8i6FT/0V0anYvI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Masami Hiramatsu , Andrew Morton , "Steven Rostedt (Google)" Subject: [PATCH 6.0 151/862] ftrace: Still disable enabled records marked as disabled Date: Wed, 19 Oct 2022 10:23:58 +0200 Message-Id: <20221019083256.655377841@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?1747119325300914096?= X-GMAIL-MSGID: =?utf-8?q?1747119325300914096?= From: Steven Rostedt (Google) commit cf04f2d5df0037741207382ac8fe289e8bf84ced upstream. Weak functions started causing havoc as they showed up in the "available_filter_functions" and this confused people as to why some functions marked as "notrace" were listed, but when enabled they did nothing. This was because weak functions can still have fentry calls, and these addresses get added to the "available_filter_functions" file. kallsyms is what converts those addresses to names, and since the weak functions are not listed in kallsyms, it would just pick the function before that. To solve this, there was a trick to detect weak functions listed, and these records would be marked as DISABLED so that they do not get enabled and are mostly ignored. As the processing of the list of all functions to figure out what is weak or not can take a long time, this process is put off into a kernel thread and run in parallel with the rest of start up. Now the issue happens whet function tracing is enabled via the kernel command line. As it starts very early in boot up, it can be enabled before the records that are weak are marked to be disabled. This causes an issue in the accounting, as the weak records are enabled by the command line function tracing, but after boot up, they are not disabled. The ftrace records have several accounting flags and a ref count. The DISABLED flag is just one. If the record is enabled before it is marked DISABLED it will get an ENABLED flag and also have its ref counter incremented. After it is marked for DISABLED, neither the ENABLED flag nor the ref counter is cleared. There's sanity checks on the records that are performed after an ftrace function is registered or unregistered, and this detected that there were records marked as ENABLED with ref counter that should not have been. Note, the module loading code uses the DISABLED flag as well to keep its functions from being modified while its being loaded and some of these flags may get set in this process. So changing the verification code to ignore DISABLED records is a no go, as it still needs to verify that the module records are working too. Also, the weak functions still are calling a trampoline. Even though they should never be called, it is dangerous to leave these weak functions calling a trampoline that is freed, so they should still be set back to nops. There's two places that need to not skip records that have the ENABLED and the DISABLED flags set. That is where the ftrace_ops is processed and sets the records ref counts, and then later when the function itself is to be updated, and the ENABLED flag gets removed. Add a helper function "skip_record()" that returns true if the record has the DISABLED flag set but not the ENABLED flag. Link: https://lkml.kernel.org/r/20221005003809.27d2b97b@gandalf.local.home Cc: Masami Hiramatsu Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: b39181f7c6907 ("ftrace: Add FTRACE_MCOUNT_MAX_OFFSET to avoid adding weak function") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman --- kernel/trace/ftrace.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1644,6 +1644,18 @@ ftrace_find_tramp_ops_any_other(struct d static struct ftrace_ops * ftrace_find_tramp_ops_next(struct dyn_ftrace *rec, struct ftrace_ops *ops); +static bool skip_record(struct dyn_ftrace *rec) +{ + /* + * At boot up, weak functions are set to disable. Function tracing + * can be enabled before they are, and they still need to be disabled now. + * If the record is disabled, still continue if it is marked as already + * enabled (this is needed to keep the accounting working). + */ + return rec->flags & FTRACE_FL_DISABLED && + !(rec->flags & FTRACE_FL_ENABLED); +} + static bool __ftrace_hash_rec_update(struct ftrace_ops *ops, int filter_hash, bool inc) @@ -1693,7 +1705,7 @@ static bool __ftrace_hash_rec_update(str int in_hash = 0; int match = 0; - if (rec->flags & FTRACE_FL_DISABLED) + if (skip_record(rec)) continue; if (all) { @@ -2126,7 +2138,7 @@ static int ftrace_check_record(struct dy ftrace_bug_type = FTRACE_BUG_UNKNOWN; - if (rec->flags & FTRACE_FL_DISABLED) + if (skip_record(rec)) return FTRACE_UPDATE_IGNORE; /* @@ -2241,7 +2253,7 @@ static int ftrace_check_record(struct dy if (update) { /* If there's no more users, clear all flags */ if (!ftrace_rec_count(rec)) - rec->flags = 0; + rec->flags &= FTRACE_FL_DISABLED; else /* * Just disable the record, but keep the ops TRAMP @@ -2634,7 +2646,7 @@ void __weak ftrace_replace_code(int mod_ do_for_each_ftrace_rec(pg, rec) { - if (rec->flags & FTRACE_FL_DISABLED) + if (skip_record(rec)) continue; failed = __ftrace_replace_code(rec, enable);