linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Christoph Hellwig <hch@lst.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: linux-next: build failure after merge of the modules tree
Date: Wed, 10 Feb 2021 17:16:31 +0100	[thread overview]
Message-ID: <YCQG3577G6C+OZPz@gunter> (raw)
In-Reply-To: <20210210232148.4f9d4a43@canb.auug.org.au>

+++ Stephen Rothwell [10/02/21 23:21 +1100]:
>Hi Jessica,
>
>On Wed, 10 Feb 2021 09:06:48 +0100 Jessica Yu <jeyu@kernel.org> wrote:
>>
>> Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
>> option was introduced around v4.7. If simply enabling it produces
>> these compilation errors I was wondering if it ever built properly on
>> powerpc.
>
>Ah, of course.  So for a quick fix, you could revert just the changes
>to lib/Kconfig and all the defconfigs.  That way all the UNUSED_SYMBOLS
>infrastructure is still removed, but TRIM_UNUSED_KSYMS remains (un)set
>whenever it used to be (un)set and that could then be cleaned up in a
>followup patch set per architecture when we know it works.

Hi Stephen,

What's maybe simpler is marking this as BROKEN on PPC64 as a temporary
fix for linux-next until Masahiro's patch (the real fix) is posted. I
think the real problem is that TRIM_UNUSED_KSYMS was pretty much
hiding behind UNUSED_SYMBOLS=y until it finally got removed. Anyway
the main point is that TRIM_UNUSED_KSYMS=y shouldn't be breaking any
builds. I've pushed this change and hope that won't break linux-next now.

---
	
 From 1fa67f8391acb88a54e7defe6b73f8f171450f4a Mon Sep 17 00:00:00 2001
From: Jessica Yu <jeyu@kernel.org>
Date: Wed, 10 Feb 2021 16:59:53 +0100
Subject: [PATCH] module: mark TRIM_UNUSED_KSYMS as BROKEN on powerpc

Commit 367948220fce, which removed CONFIG_UNUSED_SYMBOLS, unraveled the
TRIM_UNUSED_KSYMS config option to be generally available without depending
on CONFIG_UNUSED_SYMBOLS=y. With CONFIG_UNUSED_SYMBOLS gone, this means
allyesconfig will now select this option without being "behind"
CONFIG_UNUSED_SYMBOLS. Unfortunately, this revealed some underlying build
issues on powerpc. When CONFIG_TRIM_UNUSED_KSYMS is enabled on powerpc, the
build would fail like this:

In file included from include/linux/export.h:123,
                  from include/linux/linkage.h:7,
                  from arch/powerpc/include/asm/unistd.h:18,
                  from <stdin>:2:
./include/generated/autoksyms.h:5:9: warning: missing whitespace after the
macro name
     5 | #define __KSYM_.HT_update_self_and_peer_setting 1
       |         ^~~~~~~
./include/generated/autoksyms.h:6:9: warning: missing whitespace after the
macro name
     6 | #define __KSYM_.RemovePeerTS 1
       |         ^~~~~~~
./include/generated/autoksyms.h:6: warning: "__KSYM_" redefined
     6 | #define __KSYM_.RemovePeerTS 1
       |
./include/generated/autoksyms.h:5: note: this is the location of the
previous definition

This is due to the addition of a dot "." prefix to some symbols that is
specific to powerpc, which confuses the gen_autoksyms script.

This is a temporary workaround for linux-next until gen_autoksyms and
modpost gets fixed.

Link: http://lore.kernel.org/r/20210209210843.3af66662@canb.auug.org.au
Signed-off-by: Jessica Yu <jeyu@kernel.org>
---
  init/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/init/Kconfig b/init/Kconfig
index 11b803b45c19..e4504a04b601 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2264,6 +2264,7 @@ config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
  
  config TRIM_UNUSED_KSYMS
  	bool "Trim unused exported kernel symbols"
+	depends on !PPC64 || BROKEN
  	help
  	  The kernel and some modules make many symbols available for
  	  other modules to use via EXPORT_SYMBOL() and variants. Depending


  reply	other threads:[~2021-02-10 16:17 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 10:08 linux-next: build failure after merge of the modules tree Stephen Rothwell
2021-02-09 15:16 ` Jessica Yu
2021-02-09 16:06   ` Christoph Hellwig
2021-02-09 21:50   ` Stephen Rothwell
2021-02-10  8:06     ` Jessica Yu
2021-02-10  8:37       ` Masahiro Yamada
2021-02-11  6:19         ` Masahiro Yamada
2021-02-10 12:21       ` Stephen Rothwell
2021-02-10 16:16         ` Jessica Yu [this message]
     [not found] <mb_jUGmjgayTheAB5ZLGso-I856wAQhMkb6zPGnzUyAoUjhzm-QIzkGPLTe-sPI29ax91vO1D3aVy6J7rdTtgg==@protonmail.internalid>
2025-11-04  4:45 ` Stephen Rothwell
2025-11-04 10:15   ` Andreas Hindborg
2025-11-05  4:51   ` Stephen Rothwell
2025-11-05  6:15     ` Daniel Gomez
2025-12-04 22:58     ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2024-02-02  1:03 Stephen Rothwell
2022-11-14  0:13 Stephen Rothwell
2022-11-14  8:01 ` Jiri Olsa
2022-11-14  9:08   ` Leizhen (ThunderTown)
2022-02-21 16:07 broonie
2022-02-23  0:32 ` Luis Chamberlain
2022-02-28  5:13   ` Stephen Rothwell
2022-02-28 18:16     ` Luis Chamberlain
2019-06-25  4:27 Stephen Rothwell
2015-12-01 20:23 Mark Brown
2015-12-02  3:23 ` Rusty Russell
2015-11-27  1:26 Stephen Rothwell
2015-11-27  2:57 ` Rusty Russell
2015-06-25  6:54 Stephen Rothwell
2015-06-25  9:51 ` Dan Streetman
2015-06-24  1:37 Stephen Rothwell
2015-06-24 18:18 ` Dan Streetman
2015-06-24 22:57   ` Stephen Rothwell
2015-06-25  1:50     ` Stephen Rothwell
2014-12-18  2:05 Stephen Rothwell
2014-08-07  3:20 Stephen Rothwell
2014-08-07 11:37 ` Rusty Russell
2014-08-07 13:03   ` Stephen Rothwell
2014-08-07 13:07     ` Rusty Russell
2014-08-08  1:33       ` Stephen Rothwell
2014-07-28  3:58 Stephen Rothwell
2014-07-28 11:38 ` Rusty Russell
2014-03-25  3:02 Stephen Rothwell
2014-03-31  3:45 ` Rusty Russell
2012-11-26  4:10 Stephen Rothwell
2012-11-28 11:02 ` Stanislaw Gruszka
2012-12-03  0:29   ` Rusty Russell
2012-11-02  1:57 Stephen Rothwell
2012-11-02  3:16 ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YCQG3577G6C+OZPz@gunter \
    --to=jeyu@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).