Skip to contentSkip to conversation

Patch "vmlinux.lds.h: Handle clang's module.{c,d}tor sections" has been added to the 5.13-stable tree

DISCUSSION Nathan Chancellor 2 participants 2 messages Aug 15, 2021 – Aug 16, 2021 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Nathan Chancellor

author Reviewed-by Nick Desaulniers Reviewed-by Fangrui Song Acked-by Marco Elver Reviewed-by Nick Desaulniers Reviewed-by Fangrui Song Acked-by Marco Elver
#1 lore raw

Hi Greg,

Quoted 11 lines · On Sun, Aug 15, 2021 at 02:54:26PM +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

vmlinux.lds.h: Handle clang's module.{c,d}tor sections

to the 5.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
vmlinux.lds.h-handle-clang-s-module.-c-d-tor-sections.patch
and it can be found in the queue-5.13 subdirectory.

Attached are backports for 4.4 to 5.10. I am not sure if anyone is actually using KASAN with clang on 4.4 (ChromeOS maybe?) but it does not hurt to have it just in case.

I did not get any emails that the patch failed to apply on the older versions, I assume this is because I did just a "Cc: [email protected]" without any version or fixes tag. Is there any "official" way to notate that I want a particular patch applied to all supported kernel versions aside from adding "# v4.4+" to the Cc tag so that I can provide manual backports for those versions?

Cheers,
Nathan

From fd073a15e9941b70d0db84d28d539cf3535e1b59 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <[email protected]>
Date: Fri, 30 Jul 2021 19:31:08 -0700
Subject: [PATCH 4.4 to 4.14] vmlinux.lds.h: Handle clang's module.{c,d}tor
sections

commit 848378812e40152abe9b9baf58ce2004f76fb988 upstream.

A recent change in LLVM causes module_{c,d}tor sections to appear when CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings because these are not handled anywhere:

ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor' ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor' ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'

Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN flag, so it is in a separate section even with -fno-function-sections (default)".

Place them in the TEXT_TEXT section so that these technologies continue to work with the newer compiler versions. All of the KASAN and KCSAN KUnit tests continue to pass after this change.

---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)
include/asm-generic/vmlinux.lds.h +1 -0
index c9790b2cdf34..45fe7295051f 100644
@@ -465,6 +465,7 @@
 		*(.text.unknown .text.unknown.*)			\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		*(.text.asan.* .text.tsan.*)				\
 	MEM_KEEP(init.text)						\
 	MEM_KEEP(exit.text)						\
 

base-commit: 162b95d01320370b80cb2d5724cea4ae538ac740

Signature · 1 line
2.33.0.rc2

From 07154ab1ed7ce98f9418421152753e1bc8029829 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <[email protected]>
Date: Fri, 30 Jul 2021 19:31:08 -0700
Subject: [PATCH 4.19 to 5.10] vmlinux.lds.h: Handle clang's module.{c,d}tor
sections

commit 848378812e40152abe9b9baf58ce2004f76fb988 upstream.

A recent change in LLVM causes module_{c,d}tor sections to appear when CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings because these are not handled anywhere:

ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor' ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor' ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'

Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN flag, so it is in a separate section even with -fno-function-sections (default)".

Place them in the TEXT_TEXT section so that these technologies continue to work with the newer compiler versions. All of the KASAN and KCSAN KUnit tests continue to pass after this change.

---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)
include/asm-generic/vmlinux.lds.h +1 -0
index 18468b46c450..a774361f28d4 100644
@@ -599,6 +599,7 @@
 		NOINSTR_TEXT						\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		*(.text.asan.* .text.tsan.*)				\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\
 

base-commit: 5805e5eec901e830c7741d4916270d0b9cfd6743

Signature · 1 line
2.33.0.rc2
maintainer
#2 lore raw
Quoted 19 lines · Nathan Chancellor

Hi Greg,

Quoted 11 lines · On Sun, Aug 15, 2021 at 02:54:26PM +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

vmlinux.lds.h: Handle clang's module.{c,d}tor sections

to the 5.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
vmlinux.lds.h-handle-clang-s-module.-c-d-tor-sections.patch
and it can be found in the queue-5.13 subdirectory.

Attached are backports for 4.4 to 5.10. I am not sure if anyone is actually using KASAN with clang on 4.4 (ChromeOS maybe?) but it does not hurt to have it just in case.

Quoted 6 lines

I did not get any emails that the patch failed to apply on the older versions, I assume this is because I did just a "Cc: [email protected]" without any version or fixes tag. Is there any "official" way to notate that I want a particular patch applied to all supported kernel versions aside from adding "# v4.4+" to the Cc tag so that I can provide manual backports for those versions?

That comment is exactly how you should ask for that, otherwise I do a "best effort" type of backport and just stop when it does not apply.

Or you can provide a "Fixes:" tag, which will show me exactly how far back to apply patches, and that usually works better as it will catch commits that get backported to older kernels.

thanks,

greg k-h