From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6054581668504548688==" MIME-Version: 1.0 From: Greg Kroah-Hartman To: kbuild-all@lists.01.org Subject: Re: [stable:linux-5.4.y 5541/6083] ERROR: "__memcat_p" [drivers/hwtracing/stm/stm_core.ko] undefined! Date: Tue, 04 May 2021 06:42:57 +0200 Message-ID: In-Reply-To: List-Id: --===============6054581668504548688== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, May 03, 2021 at 09:16:42PM +0200, Arnd Bergmann wrote: > On Mon, May 3, 2021 at 7:00 PM 'Nick Desaulniers' via Clang Built > Linux wrote: > > > > >> ERROR: "__memcat_p" [drivers/hwtracing/stm/stm_core.ko] undefine= d! > > > > > > I'm fairly sure this is unrelated to my patch, but I don't see what > > > happened here. > > > > It's unrelated to your patch. It was fixed in 5.7 by > > 7273ad2b08f8ac9563579d16a3cf528857b26f49 and a few other dependencies > > according to https://github.com/ClangBuiltLinux/linux/issues/515. > > > = > Ah right, the big hammer. > = > Greg, not sure what we want to do here. Backporting > = > 7273ad2b08f8 ("kbuild: link lib-y objects to vmlinux forcibly when > CONFIG_MODULES=3Dy") > = > to v5.4 and earlier would be an easy workaround, but it has the potential > of adding extra bloat to the kernel image since it links in all other > library objects as well. I've lost the thread here, but what _real_ problem is happening here that doing the above is required? thanks, greg k-h --===============6054581668504548688==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D2E9C433B4 for ; Tue, 4 May 2021 04:43:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 092D5613B4 for ; Tue, 4 May 2021 04:43:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 092D5613B4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 569916B0070; Tue, 4 May 2021 00:43:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5182C6B0071; Tue, 4 May 2021 00:43:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B7FC6B0072; Tue, 4 May 2021 00:43:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id 1FA096B0070 for ; Tue, 4 May 2021 00:43:02 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CD8AB9091 for ; Tue, 4 May 2021 04:43:01 +0000 (UTC) X-FDA: 78102303762.36.14DFD7C Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf21.hostedemail.com (Postfix) with ESMTP id 47B4DE000118 for ; Tue, 4 May 2021 04:42:57 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D13F161076; Tue, 4 May 2021 04:42:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620103380; bh=aDIexvMx+Nj3gvtxPKQXaCPTeb7I8Bm2MAOIhitUt9g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cjngS0LSFvEWgtN/m9C/rNEggQ5zz5Xxs3aDUnotlGwbXZABfimhOMzFroKE39EdO V6OJRqevKtq/8ZwoS726gRtCI4fnYX2gEkHqZF9hUmx8J9efmNYYjM9XwT16uyQD5k yDO6Z0MJiCAOUvnkps4SfKGLLiiyfl8R3Cp9RvfA= Date: Tue, 4 May 2021 06:42:57 +0200 From: Greg Kroah-Hartman To: Arnd Bergmann Cc: Nick Desaulniers , kernel test robot , kbuild-all@lists.01.org, clang-built-linux , Andrew Morton , Linux Memory Management List , Sasha Levin , Alexander Shishkin , Masahiro Yamada , stable Subject: Re: [stable:linux-5.4.y 5541/6083] ERROR: "__memcat_p" [drivers/hwtracing/stm/stm_core.ko] undefined! Message-ID: References: <202105030311.xWwkyV9z-lkp@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=cjngS0LS; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf21.hostedemail.com: domain of gregkh@linuxfoundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 47B4DE000118 X-Stat-Signature: hacenokxn879ciowfayfjy4hzhxmjj6r Received-SPF: none (linuxfoundation.org>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620103377-439506 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 03, 2021 at 09:16:42PM +0200, Arnd Bergmann wrote: > On Mon, May 3, 2021 at 7:00 PM 'Nick Desaulniers' via Clang Built > Linux wrote: > > > > >> ERROR: "__memcat_p" [drivers/hwtracing/stm/stm_core.ko] undefined! > > > > > > I'm fairly sure this is unrelated to my patch, but I don't see what > > > happened here. > > > > It's unrelated to your patch. It was fixed in 5.7 by > > 7273ad2b08f8ac9563579d16a3cf528857b26f49 and a few other dependencies > > according to https://github.com/ClangBuiltLinux/linux/issues/515. > > > > Ah right, the big hammer. > > Greg, not sure what we want to do here. Backporting > > 7273ad2b08f8 ("kbuild: link lib-y objects to vmlinux forcibly when > CONFIG_MODULES=y") > > to v5.4 and earlier would be an easy workaround, but it has the potential > of adding extra bloat to the kernel image since it links in all other > library objects as well. I've lost the thread here, but what _real_ problem is happening here that doing the above is required? thanks, greg k-h