Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3360007pxb; Mon, 17 Jan 2022 18:33:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJwtSv9c7c3jwbPIXnYAf3bkA6jxJHvCHNWBjBKawTwC1A0zY+9nYqL82pzPzPeKGtmYP1WW X-Received: by 2002:a63:7c10:: with SMTP id x16mr21595681pgc.128.1642473235849; Mon, 17 Jan 2022 18:33:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642473235; cv=none; d=google.com; s=arc-20160816; b=d01sr85een8id7QU8xLFIXF+xcSZcigpV0gqCZY8sE99hxF6PxgyydlS9xnMscms/Y QjxtOYzU7Z3qBsxfwsQtli4hj97vmb33AKKC+i+bcOgM9NelJj2pGpL8Y3pbeBct2sJk rt5hkkHCM8IkIRg1FnjtpDgd0cKhxjtK9zno0fIc4UZO7689JY2e1NcY5AUNfdpzW/oX e/JphiRYait2g5VddpO0DfiBMHXTYeZsq2/1Fn2vmlnFpopQ2lHfa0lH8KsXnuzpPrwh 0GtJ/UyGkxjgHUqPxCf4U1jX0/xKlxqYNqiRh0Ccv0u+1KGWj1pA/frLWg5osKkkd54M ZB1A== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=kOktTZlzwmwOY/F8tXqENRSkoS+ndZHgEnSdkl/ZSMU=; b=gRt2sb3A4fH38rkAHjW1wzowDCp2JYUsjUM9ynOJsc9EfqG9kDWoMquyi+uVvo3UU/ DWUA9Dmj7JPO4vXz3sFzKn2jCGtmXlAlcUSfNhZWCGo7LZ5f2rVqXYj4W7XZkMaej9kh 7CWMtES6kbg4HzuoboS//qb9OBxA7mZRh75N3xUiA29Nm1kddXvCKjQB5vrCnxBOrXcX jFizb4RYB+MYIp3sc+2ygYgUjp1jVVuMN+Tv+skBuLLgFiNb709lRepQOYyt8jZgd8md JMqNt8w0fdYNTxVqpv5ALR8HUP49kP90atDkzSaJqj3/mXAoFZeQTF3+xNHpikOT2b3u YXDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r13si1093448pjp.79.2022.01.17.18.33.44; Mon, 17 Jan 2022 18:33:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240287AbiAQPOU (ORCPT + 99 others); Mon, 17 Jan 2022 10:14:20 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:54410 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234737AbiAQPOS (ORCPT ); Mon, 17 Jan 2022 10:14:18 -0500 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 8BBCAB80EF1 for ; Mon, 17 Jan 2022 15:14:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6AFD0C36AE7; Mon, 17 Jan 2022 15:14:15 +0000 (UTC) Date: Mon, 17 Jan 2022 10:14:13 -0500 From: Steven Rostedt To: "Chen, Rong A" Cc: kernel test robot , kbuild-all@lists.01.org, linux-kernel@vger.kernel.org Subject: Re: [kbuild-all] Re: WARNING: modpost: vmlinux.o(.text.unlikely+0x2c44): Section mismatch in reference from the function trace_define_generic_fields() to the variable .init.data:initcall_level_names Message-ID: <20220117101413.51edd7fa@rorschach.local.home> In-Reply-To: References: <202112210114.CFpCHRci-lkp@intel.com> <20220110185100.6c4c226c@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 Jan 2022 16:32:38 +0800 "Chen, Rong A" wrote: > > > > Please tell me where initcall_level_names is being referenced? > > > > Either fix the compiler or tell me exactly what the bug is. Otherwise, stop > > sending me this. > > > > -- Steve > > Hi Steve, > > I'm not familiar with the code, the warning can be silenced with the > below change: > > --- a/kernel/trace/trace_events.c > +++ b/kernel/trace/trace_events.c > @@ -162,7 +162,7 @@ EXPORT_SYMBOL_GPL(trace_define_field); > if (ret) \ > return ret; > > -static int trace_define_generic_fields(void) > +static __init int trace_define_generic_fields(void) > { > int ret; > > @@ -174,7 +174,7 @@ static int trace_define_generic_fields(void) > return ret; > } > > -static int trace_define_common_fields(void) > +static __init int trace_define_common_fields(void) > { > int ret; > struct trace_entry ent; > > If the warning can't be fixed, we'll add the warning to the ignore list. > So the issue is that an __init function calls a static function that isn't marked as __init? I guess it can be updated, but seriously, there's nothing bad that can happen with the above, and it still looks to me as an over aggressive compiler. -- Steve