All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>,
	Mathieu Malaterre <malat@debian.org>,
	Nicholas Piggin <npiggin@gmail.com>
Subject: Re: linux-next: build warning after merge of the akpm tree
Date: Tue, 8 Dec 2020 23:01:57 +1100	[thread overview]
Message-ID: <20201208230157.42c42789@canb.auug.org.au> (raw)
In-Reply-To: <20201204210000.660293c6@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

Hi Stephen,

On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) produced warnings like this:
> 
> ld: warning: orphan section `.data..Lubsan_data177' from `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section `.data..Lubsan_data177'
> 
> (lots of these latter ones)

781584 of them today!

> I don't know what produced these, but it is in the akpm-current or
> akpm trees.

Presumably the result of commit

  186c3e18dba3 ("ubsan: enable for all*config builds")

from the akpm-current tree.

arch/powerpc/kernel/vmlinux.lds.S has:

#ifdef CONFIG_PPC32
        .data : AT(ADDR(.data) - LOAD_OFFSET) {
                DATA_DATA
#ifdef CONFIG_UBSAN
                *(.data..Lubsan_data*)
                *(.data..Lubsan_type*)
#endif
                *(.data.rel*)
                *(SDATA_MAIN)

added by commit

  beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly")

in 2018, but no equivalent for 64 bit.

I will try the following patch tomorrow:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Dec 2020 22:58:24 +1100
Subject: [PATCH] powerpc: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly

Similarly to commit

  beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly")

since CONFIG_UBSAN bits can now be enabled for all*config.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/vmlinux.lds.S | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 3b4c26e94328..0318ba436f34 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -296,6 +296,10 @@ SECTIONS
 #else
 	.data : AT(ADDR(.data) - LOAD_OFFSET) {
 		DATA_DATA
+#ifdef CONFIG_UBSAN
+		*(.data..Lubsan_data*)
+		*(.data..Lubsan_type*)
+#endif
 		*(.data.rel*)
 		*(.toc1)
 		*(.branch_lt)
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>,
	Mathieu Malaterre <malat@debian.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>
Subject: Re: linux-next: build warning after merge of the akpm tree
Date: Tue, 8 Dec 2020 23:01:57 +1100	[thread overview]
Message-ID: <20201208230157.42c42789@canb.auug.org.au> (raw)
In-Reply-To: <20201204210000.660293c6@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

Hi Stephen,

On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) produced warnings like this:
> 
> ld: warning: orphan section `.data..Lubsan_data177' from `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section `.data..Lubsan_data177'
> 
> (lots of these latter ones)

781584 of them today!

> I don't know what produced these, but it is in the akpm-current or
> akpm trees.

Presumably the result of commit

  186c3e18dba3 ("ubsan: enable for all*config builds")

from the akpm-current tree.

arch/powerpc/kernel/vmlinux.lds.S has:

#ifdef CONFIG_PPC32
        .data : AT(ADDR(.data) - LOAD_OFFSET) {
                DATA_DATA
#ifdef CONFIG_UBSAN
                *(.data..Lubsan_data*)
                *(.data..Lubsan_type*)
#endif
                *(.data.rel*)
                *(SDATA_MAIN)

added by commit

  beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly")

in 2018, but no equivalent for 64 bit.

I will try the following patch tomorrow:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Dec 2020 22:58:24 +1100
Subject: [PATCH] powerpc: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly

Similarly to commit

  beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly")

since CONFIG_UBSAN bits can now be enabled for all*config.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/vmlinux.lds.S | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 3b4c26e94328..0318ba436f34 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -296,6 +296,10 @@ SECTIONS
 #else
 	.data : AT(ADDR(.data) - LOAD_OFFSET) {
 		DATA_DATA
+#ifdef CONFIG_UBSAN
+		*(.data..Lubsan_data*)
+		*(.data..Lubsan_type*)
+#endif
 		*(.data.rel*)
 		*(.toc1)
 		*(.branch_lt)
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-12-08 12:02 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 10:00 linux-next: build warning after merge of the akpm tree Stephen Rothwell
2020-12-05  5:19 ` Andrew Morton
2020-12-05  9:37   ` Stephen Rothwell
2020-12-07 12:08   ` Dmitry Vyukov
2020-12-07 12:38     ` Dmitry Vyukov
2020-12-07 12:52       ` Marco Elver
2020-12-09 10:06         ` Dmitry Vyukov
2020-12-08 12:01 ` Stephen Rothwell [this message]
2020-12-08 12:01   ` Stephen Rothwell
2020-12-09  4:44   ` Michael Ellerman
2020-12-09  4:44     ` Michael Ellerman
2020-12-09  7:07     ` Stephen Rothwell
2020-12-09  7:07       ` Stephen Rothwell
2020-12-10  0:19       ` Michael Ellerman
2020-12-10  0:19         ` Michael Ellerman
2020-12-10 21:17         ` Stephen Rothwell
2020-12-10 21:17           ` Stephen Rothwell
2020-12-09 10:33   ` Stephen Rothwell
2020-12-09 10:33     ` Stephen Rothwell
2020-12-09 18:56   ` Kees Cook
2020-12-09 18:56     ` Kees Cook
  -- strict thread matches above, loose matches on Subject: below --
2021-01-28  8:46 Stephen Rothwell
2021-02-01  7:14 ` Vijayanand Jitta
2020-02-28  4:35 Stephen Rothwell
2020-02-28  5:23 ` Arjun Roy
2020-01-06  6:11 Stephen Rothwell
2020-01-06  6:07 Stephen Rothwell
2020-01-07 23:11 ` Andrew Morton
2020-01-08 14:52   ` Steven Price
2018-11-30  5:40 Stephen Rothwell
2018-11-30 14:52 ` Dave Rodgman
2017-08-01  6:02 Stephen Rothwell
2017-08-01  6:15 ` Huang, Ying
2017-08-01 21:15   ` Arnd Bergmann
2017-06-26  6:30 Stephen Rothwell
2017-06-26 23:57 ` Wei Yang
2014-05-19  8:13 Stephen Rothwell
2014-05-19 15:13 ` Davidlohr Bueso
2014-05-19 19:48   ` Andrew Morton
2014-05-19 20:56     ` Davidlohr Bueso
2014-05-19 21:17       ` Andrew Morton
2014-05-19 21:36   ` Stephen Rothwell
2014-05-19 22:38     ` Davidlohr Bueso
2013-04-18  8:03 Stephen Rothwell
2013-04-10  8:33 Stephen Rothwell
2013-04-10  8:18 Stephen Rothwell
2013-02-20  6:34 Stephen Rothwell
2013-02-20 14:37 ` Peter Jones
2013-01-23  6:33 Stephen Rothwell
2013-01-23  6:43 ` Tang Chen
2012-11-09  3:43 Stephen Rothwell
2012-11-09 10:00 ` Grant Likely
2012-10-25  3:35 Stephen Rothwell
2012-04-27  5:44 Stephen Rothwell
2012-04-27  6:22 ` Cyrill Gorcunov
2012-04-27  6:28   ` Stephen Rothwell
2012-04-27  6:40     ` Cyrill Gorcunov
2011-08-10  2:13 Stephen Rothwell

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=20201208230157.42c42789@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=malat@debian.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.