Message ID | 20230710212958.274126-1-zhengyejian1@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp4901275vqx; Mon, 10 Jul 2023 02:41:57 -0700 (PDT) X-Google-Smtp-Source: APBJJlG6/qSmQflkgBxE71d3yqywjO0eJXy+nW0YoaesB1ZE+umTH3uaVBqBkU6rtO07rbobAGgS X-Received: by 2002:a05:6e02:610:b0:341:f920:4483 with SMTP id t16-20020a056e02061000b00341f9204483mr11100468ils.9.1688982117019; Mon, 10 Jul 2023 02:41:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688982116; cv=none; d=google.com; s=arc-20160816; b=Pkel+QeccloNCg8QAP0FlBj/ePlS2shAAQ2nsHR/H2/egZJiKS8PPIkTIGSRVU1QaF Y9m1j3d5O397tdx5CnlXyDgkvScSeCgduFO3SUYCwaddKJTFQdD+jVV61vRCseM/ICcz n1pargsxW6PVgM5uyhq05IngPMXURfZmX29AS7Kl0t8KnSX6U9sZtgIj6YeOA0WMzPcB S9k9eHVLAfalyQ7ZWYZr1Ud2CO8S/78DjxjJVFJyxx/T8qD60ffpLJJCBwlVYuL+0TCT ocn1ks/Pcpl2vQ04LwPIf1CSpllVB0DOlOogM2M0zHwV7a4Wb4v/+ur4D2rOc693F9ZG h3eA== 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:date:subject:cc:to:from; bh=3OZBqYUQrYqJNCmqeCI0XIuGr9HQjBnn2fi8c3uOowI=; fh=gI9FEBZwCPkanigZF8HYbw13aijx656e2P76SW8PY5Y=; b=UFpQvZCbmC2zQh/3DIjFf/g1SO6X9TvnGXMGWFRoyowzs78RNCI6YqEOXP7PclEvP/ NEwFVA7jgAS5T3jsQ2iwQboJ5l/DrzAADuKJ/U8HM65Vt/SjwjFoDrUJjZP3m4iMeto+ Rp3pLXMXpjPlM9gxS0tQMqu68MtHuSeNSH9Blz7cWdJ7oJuwM3d6rIOyXvPoR5DwCBMg zaQC/1mYTNmCJwOmzz39NslwPP06r0roHTK1FUeS/xC/yo834HpUgKIND3q+S8cu70qW xq/b8nVlmhKS/IWZuBRIOrO+CR6wEd7fNho9ShhZ05UC3WZEhJ6PBvanzj9/oCjSPBL3 KYiw== 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r195-20020a632bcc000000b0055bac19d21bsi2723056pgr.679.2023.07.10.02.41.44; Mon, 10 Jul 2023 02:41:56 -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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229496AbjGJJca (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Mon, 10 Jul 2023 05:32:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232797AbjGJJbz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 10 Jul 2023 05:31:55 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DF692D45; Mon, 10 Jul 2023 02:30:20 -0700 (PDT) Received: from dggpeml500012.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QzzFR1QR2zTmRB; Mon, 10 Jul 2023 17:28:11 +0800 (CST) Received: from localhost.localdomain (10.67.175.61) by dggpeml500012.china.huawei.com (7.185.36.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 10 Jul 2023 17:29:21 +0800 From: Zheng Yejian <zhengyejian1@huawei.com> To: <rostedt@goodmis.org>, <mhiramat@kernel.org> CC: <linux-kernel@vger.kernel.org>, <linux-trace-kernel@vger.kernel.org>, <zhengyejian1@huawei.com> Subject: [PATCH] ftrace: Fix possible warning on checking all pages used in ftrace_process_locs() Date: Tue, 11 Jul 2023 05:29:58 +0800 Message-ID: <20230710212958.274126-1-zhengyejian1@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.175.61] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpeml500012.china.huawei.com (7.185.36.15) X-CFilter-Loop: Reflected X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_06_12, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: INBOX X-GMAIL-THRID: 1771026112620047218 X-GMAIL-MSGID: 1771026112620047218 |
Series |
ftrace: Fix possible warning on checking all pages used in ftrace_process_locs()
|
|
Commit Message
Zheng Yejian
July 10, 2023, 9:29 p.m. UTC
As comments in ftrace_process_locs(), there may be NULL pointers in mcount_loc section: > Some architecture linkers will pad between > the different mcount_loc sections of different > object files to satisfy alignments. > Skip any NULL pointers. After 20e5227e9f55 ("ftrace: allow NULL pointers in mcount_loc"), NULL pointers will be accounted when allocating ftrace pages but skipped before adding into ftrace pages, this may result in some pages not being used. Then after 706c81f87f84 ("ftrace: Remove extra helper functions"), warning may occur at: WARN_ON(pg->next); So we may need to skip NULL pointers before allocating ftrace pages. Fixes: 706c81f87f84 ("ftrace: Remove extra helper functions") Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com> --- kernel/trace/ftrace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
Comments
On Tue, 11 Jul 2023 05:29:58 +0800 Zheng Yejian <zhengyejian1@huawei.com> wrote: > As comments in ftrace_process_locs(), there may be NULL pointers in > mcount_loc section: > > Some architecture linkers will pad between > > the different mcount_loc sections of different > > object files to satisfy alignments. > > Skip any NULL pointers. > > After 20e5227e9f55 ("ftrace: allow NULL pointers in mcount_loc"), > NULL pointers will be accounted when allocating ftrace pages but > skipped before adding into ftrace pages, this may result in some > pages not being used. Then after 706c81f87f84 ("ftrace: Remove extra > helper functions"), warning may occur at: > WARN_ON(pg->next); > > So we may need to skip NULL pointers before allocating ftrace pages. > > Fixes: 706c81f87f84 ("ftrace: Remove extra helper functions") > Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com> > --- > kernel/trace/ftrace.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index 3740aca79fe7..5b474165df31 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -6485,6 +6485,16 @@ static int ftrace_process_locs(struct module *mod, > if (!count) > return 0; > > + p = start; > + while (p < end) { > + /* > + * Refer to conments below, there may be NULL pointers, > + * skip them before allocating pages > + */ > + addr = ftrace_call_adjust(*p++); > + if (!addr) > + count--; > + } My main concern about this is the added overhead during boot to process this. There's 10s of thousands of functions, so this loop will be 10s of thousands. I also don't like that this is an unconditional loop (meaning it executes even when it is unnecessary to do so). > /* > * Sorting mcount in vmlinux at build time depend on > * CONFIG_BUILDTIME_MCOUNT_SORT, while mcount loc in How about something like this? -- Steve diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index b24c573934af..acd033371721 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6474,6 +6474,7 @@ static int ftrace_process_locs(struct module *mod, struct ftrace_page *start_pg; struct ftrace_page *pg; struct dyn_ftrace *rec; + unsigned long skipped = 0; unsigned long count; unsigned long *p; unsigned long addr; @@ -6536,8 +6537,10 @@ static int ftrace_process_locs(struct module *mod, * object files to satisfy alignments. * Skip any NULL pointers. */ - if (!addr) + if (!addr) { + skipped++; continue; + } end_offset = (pg->index+1) * sizeof(pg->records[0]); if (end_offset > PAGE_SIZE << pg->order) { @@ -6551,12 +6554,24 @@ static int ftrace_process_locs(struct module *mod, rec->ip = addr; } - /* We should have used all pages */ - WARN_ON(pg->next); - /* Assign the last page to ftrace_pages */ ftrace_pages = pg; + /* We should have used all pages unless we skipped some */ + if (pg->next) { + WARN_ON(!skipped); + while (ftrace_pages->next) { + pg = ftrace_pages->next; + ftrace_pages->next = pg->next; + if (pg->records) { + free_pages((unsigned long)pg->records, pg->order); + ftrace_number_of_pages -= 1 << pg->order; + } + kfree(pg); + ftrace_number_of_groups--; + } + } + /* * We only need to disable interrupts on start up * because we are modifying code that an interrupt
On 2023/7/10 22:46, Steven Rostedt wrote: > On Tue, 11 Jul 2023 05:29:58 +0800 > Zheng Yejian <zhengyejian1@huawei.com> wrote: > >> As comments in ftrace_process_locs(), there may be NULL pointers in >> mcount_loc section: >> > Some architecture linkers will pad between >> > the different mcount_loc sections of different >> > object files to satisfy alignments. >> > Skip any NULL pointers. >> >> After 20e5227e9f55 ("ftrace: allow NULL pointers in mcount_loc"), >> NULL pointers will be accounted when allocating ftrace pages but >> skipped before adding into ftrace pages, this may result in some >> pages not being used. Then after 706c81f87f84 ("ftrace: Remove extra >> helper functions"), warning may occur at: >> WARN_ON(pg->next); >> >> So we may need to skip NULL pointers before allocating ftrace pages. >> >> Fixes: 706c81f87f84 ("ftrace: Remove extra helper functions") >> Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com> >> --- >> kernel/trace/ftrace.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c >> index 3740aca79fe7..5b474165df31 100644 >> --- a/kernel/trace/ftrace.c >> +++ b/kernel/trace/ftrace.c >> @@ -6485,6 +6485,16 @@ static int ftrace_process_locs(struct module *mod, >> if (!count) >> return 0; >> >> + p = start; >> + while (p < end) { >> + /* >> + * Refer to conments below, there may be NULL pointers, >> + * skip them before allocating pages >> + */ >> + addr = ftrace_call_adjust(*p++); >> + if (!addr) >> + count--; >> + } > > My main concern about this is the added overhead during boot to process > this. There's 10s of thousands of functions, so this loop will be 10s of > thousands. I also don't like that this is an unconditional loop (meaning it > executes even when it is unnecessary to do so). > Agreed! The added overhead probably superfluousin in most cases. > >> /* >> * Sorting mcount in vmlinux at build time depend on >> * CONFIG_BUILDTIME_MCOUNT_SORT, while mcount loc in > > How about something like this? > > -- Steve > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index b24c573934af..acd033371721 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -6474,6 +6474,7 @@ static int ftrace_process_locs(struct module *mod, > struct ftrace_page *start_pg; > struct ftrace_page *pg; > struct dyn_ftrace *rec; > + unsigned long skipped = 0; > unsigned long count; > unsigned long *p; > unsigned long addr; > @@ -6536,8 +6537,10 @@ static int ftrace_process_locs(struct module *mod, > * object files to satisfy alignments. > * Skip any NULL pointers. > */ > - if (!addr) > + if (!addr) { > + skipped++; > continue; > + } > > end_offset = (pg->index+1) * sizeof(pg->records[0]); > if (end_offset > PAGE_SIZE << pg->order) { > @@ -6551,12 +6554,24 @@ static int ftrace_process_locs(struct module *mod, > rec->ip = addr; > } > > - /* We should have used all pages */ > - WARN_ON(pg->next); > - > /* Assign the last page to ftrace_pages */ > ftrace_pages = pg; > > + /* We should have used all pages unless we skipped some */ > + if (pg->next) { > + WARN_ON(!skipped); > + while (ftrace_pages->next) { > + pg = ftrace_pages->next; > + ftrace_pages->next = pg->next; > + if (pg->records) { > + free_pages((unsigned long)pg->records, pg->order); > + ftrace_number_of_pages -= 1 << pg->order; > + } > + kfree(pg); > + ftrace_number_of_groups--; > + } Do we only need to free the pages that not being used? > + } > + > /* > * We only need to disable interrupts on start up > * because we are modifying code that an interrupt >
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 3740aca79fe7..5b474165df31 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6485,6 +6485,16 @@ static int ftrace_process_locs(struct module *mod, if (!count) return 0; + p = start; + while (p < end) { + /* + * Refer to conments below, there may be NULL pointers, + * skip them before allocating pages + */ + addr = ftrace_call_adjust(*p++); + if (!addr) + count--; + } /* * Sorting mcount in vmlinux at build time depend on * CONFIG_BUILDTIME_MCOUNT_SORT, while mcount loc in