convert dynamic_debug to use jump labels

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

text data bss dec hex filename
8194852 4879776 925696 14000324 d5a0c4 vmlinux.pre
8187337 4960224 925696 14073257 d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

Quoted 6 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

text data bss dec hex filename
8194852 4879776 925696 14000324 d5a0c4 vmlinux.pre
8187337 4960224 925696 14073257 d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o .exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o

Arnd

Quoted 17 lines · Arnd Bergmann

Quoted 6 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

text data bss dec hex filename

8194852      4879776  925696 14000324         d5a0c4 vmlinux.pre
8187337      4960224  925696 14073257         d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

Quoted 3 lines

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o .exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o

I stuck pr_debug() in a few functions marked with __exit, but did not reproduce yet. Can you share your .config and gcc --version.

Quoted 18 lines · CEST Jason Baron

Quoted 17 lines · Arnd Bergmann

Quoted 6 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

text data bss dec hex filename

8194852      4879776  925696 14000324         d5a0c4 vmlinux.pre
8187337      4960224  925696 14073257         d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

Quoted 7 lines

Quoted 3 lines

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o .exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o

I stuck pr_debug() in a few functions marked with __exit, but did not reproduce yet. Can you share your .config and gcc --version.

I found these on ARM randconfig builds e.g. this one
http://pastebin.com/raw/KjWHxnwU

I also have some other patches applied that could have interacted with your change, so if you can't reproduce it easily, let me try it on a plain linux-next kernel.

The compiler I use is arm-linux-gnueabi-gcc (GCC) 6.0.0 20160323 (experimental)

Quoted 34 lines · CEST Arnd Bergmann

Quoted 18 lines · CEST Jason Baron

Quoted 17 lines · Arnd Bergmann

Quoted 6 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

text data bss dec hex filename

8194852      4879776  925696 14000324         d5a0c4 vmlinux.pre
8187337      4960224  925696 14073257         d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

Quoted 7 lines

Quoted 3 lines

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o .exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o

I stuck pr_debug() in a few functions marked with __exit, but did not reproduce yet. Can you share your .config and gcc --version.

I found these on ARM randconfig builds e.g. this one
http://pastebin.com/raw/KjWHxnwU

I also have some other patches applied that could have interacted with your change, so if you can't reproduce it easily, let me try it on a plain linux-next kernel.

Quoted 1 line

The compiler I use is arm-linux-gnueabi-gcc (GCC) 6.0.0 20160323 (experimental)

Update: on ARM, I have been able to reproduce this with gcc-4.6 and gcc-4.8, so I'm pretty confident that this is independent of the toolchain. However, I have so far failed to reproduce this on x86.

Looking at the exit_ceph() function, I get these two assembly outputs, ARM fails with the link error above:

Quoted 35 lines · Arnd Bergmann

Quoted 34 lines · CEST Arnd Bergmann

Quoted 18 lines · CEST Jason Baron

Quoted 17 lines · Arnd Bergmann

Quoted 6 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

text data bss dec hex filename

8194852      4879776  925696 14000324         d5a0c4 vmlinux.pre
8187337      4960224  925696 14073257         d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

Quoted 7 lines

Quoted 3 lines

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o .exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o

I stuck pr_debug() in a few functions marked with __exit, but did not reproduce yet. Can you share your .config and gcc --version.

I found these on ARM randconfig builds e.g. this one
http://pastebin.com/raw/KjWHxnwU

I also have some other patches applied that could have interacted with your change, so if you can't reproduce it easily, let me try it on a plain linux-next kernel.

Quoted 9 lines

Quoted 1 line

The compiler I use is arm-linux-gnueabi-gcc (GCC) 6.0.0 20160323 (experimental)

Update: on ARM, I have been able to reproduce this with gcc-4.6 and gcc-4.8, so I'm pretty confident that this is independent of the toolchain. However, I have so far failed to reproduce this on x86.

Looking at the exit_ceph() function, I get these two assembly outputs, ARM fails with the link error above:

ok, does this fix things up?

Hi Arnd,

Ok, this is back in linux-next now (with hopefully a fix for arm). I was never able to quite reproduce the arm failure you saw. So if you get the chance to test this it would be great.

Quoted 6 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

text data bss dec hex filename
8194852 4879776 925696 14000324 d5a0c4 vmlinux.pre
8187337 4960224 925696 14073257 d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o .exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o

Arnd

Quoted 13 lines · Arnd Bergmann

Quoted 6 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its enabled for production builds as well. Minimize its impact by using jump labels. This reduces the text section by 7000+ bytes in the kernel image below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

text data bss dec hex filename
8194852 4879776 925696 14000324 d5a0c4 vmlinux.pre
8187337 4960224 925696 14073257 d6bda9 vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

Quoted 8 lines

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o .exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section .exit.text' of drivers/built-in.o

Arnd

Hi Arnd,

Ok, I managed to reproduce this on tile and sparc64 by adding static_branch_[un]likely() to __exit functions as you mentioned. Although I didn't find the actual broken config.

I think its only an issue on those 2 arches b/c they have jump label support and discard __exit text at build time (most arches seem to do it at run-time). Thus, we can end up with references in the __jump_table to addresses that may be in an __exit section. The jump label code already protects itself from touch code in the init sections after it has been freed. Thus, simply having functions marked with __exit in the init section is sufficient here.

arch/tile/kernel/vmlinux.lds.S +0 -0

@@ -58,7 +58,21 @@ SECTIONS
    _etext = .;
 
    /* "Init" is divided into two areas with very different virtual

addresses. */

arch/tile/kernel/vmlinux.lds.S +7 -0

+  . = ALIGN(PAGE_SIZE);
+  .init.begin : AT(ADDR(.init.begin) - LOAD_OFFSET) {
+     __init_begin = .; /* paired with __init_end */
+  }
+
    INIT_TEXT_SECTION(PAGE_SIZE)
+  .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
+       EXIT_TEXT

Quoted 35 lines · Jason Baron

Quoted 19 lines · Arnd Bergmann

Quoted 9 lines · CEST Jason Baron

Although dynamic debug is often only used for debug builds, sometimes its
enabled for production builds as well. Minimize its impact by using jump
labels. This reduces the text section by 7000+ bytes in the kernel image
below. It does increase data, but this should only be referenced when changing the direction of the branches, and hence usually not in cache.

Quoted 6 lines

    text       data        bss        dec        hex    filename
8194852    4879776     925696    14000324     d5a0c4    vmlinux.pre
8187337    4960224     925696    14073257     d6bda9    vmlinux.post

Signed-off-by Jason Baron <[email protected]>

---

This causes problems for some of my randconfig builds, when a dynamic debug call is used inside of an __exit function:

Quoted 9 lines

.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
.exit.text' referenced in section __jump_table' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o

Arnd

Hi Arnd,

Ok, I managed to reproduce this on tile and sparc64 by adding static_branch_[un]likely() to __exit functions as you mentioned. Although I didn't find the actual broken config.

Quoted 8 lines

I think its only an issue on those 2 arches b/c they have jump label support and discard __exit text at build time (most arches seem to do it at run-time). Thus, we can end up with references in the __jump_table to addresses that may be in an __exit section. The jump label code already protects itself from touch code in the init sections after it has been freed. Thus, simply having functions marked with __exit in the init section is sufficient here.

It seems plausible to me to only include the exit text in with the init text
under an #ifdef CONFIG_JUMP_TABLE (with a suitable comment) in any case, because if we don't need to include it in the image, then why do so? It adds about 7KB to the loaded size of the vmlinux image for no gain (on a typical tilegx configuration).

Quoted 15 lines

arch/tile/kernel/vmlinux.lds.S +0 -0

@@ -58,7 +58,21 @@ SECTIONS
    _etext = .;
 
    /* "Init" is divided into two areas with very different virtual

addresses. */

arch/tile/kernel/vmlinux.lds.S +7 -0

+  . = ALIGN(PAGE_SIZE);
+  .init.begin : AT(ADDR(.init.begin) - LOAD_OFFSET) {
+     __init_begin = .; /* paired with __init_end */
+  }
+
    INIT_TEXT_SECTION(PAGE_SIZE)
+  .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
+       EXIT_TEXT

arch/tile/kernel/vmlinux.lds.S

Quoted 10 lines

arch/tile/kernel/vmlinux.lds.S +7 -0

+  }
+
+  . = ALIGN(PAGE_SIZE);
+  /* freed after init ends here */
+  .init.end : AT(ADDR(.init.end) - LOAD_OFFSET) {
+       __init_end = .;
+  }
 
    /* Now we skip back to PAGE_OFFSET for the data. */
    . = (. - TEXT_OFFSET + PAGE_OFFSET);

This doesn't look right to me; we already have an __init_begin symbol defined a few lines further down in vmlinux.lds.S. How does this patch work instead?

arch/tile/kernel/vmlinux.lds.S +0 -0

index 378f5d8d1ec8..5e83d2689def 100644
@@ -58,7 +58,15 @@ SECTIONS
   _etext = .;
 
   /* "Init" is divided into two areas with very different virtual

addresses. */

arch/tile/kernel/vmlinux.lds.S +2 -1

-  INIT_TEXT_SECTION(PAGE_SIZE)
+  . = ALIGN(PAGE_SIZE);
+  .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {

Quoted 31 lines · Chris Metcalf

Quoted 6 lines · Jason Baron

Hi Arnd,

Ok, I managed to reproduce this on tile and sparc64 by adding static_branch_[un]likely() to __exit functions as you mentioned. Although I didn't find the actual broken config.

Quoted 8 lines

I think its only an issue on those 2 arches b/c they have jump label support and discard __exit text at build time (most arches seem to do it at run-time). Thus, we can end up with references in the __jump_table to addresses that may be in an __exit section. The jump label code already protects itself from touch code in the init sections after it has been freed. Thus, simply having functions marked with __exit in the init section is sufficient here.

How does this patch work instead?

arch/tile/kernel/vmlinux.lds.S +0 -0

index 378f5d8d1ec8..5e83d2689def 100644
@@ -58,7 +58,15 @@ SECTIONS
    _etext = .;
 
    /* "Init" is divided into two areas with very different virtual

addresses. */

arch/tile/kernel/vmlinux.lds.S +2 -1

-  INIT_TEXT_SECTION(PAGE_SIZE)
+  . = ALIGN(PAGE_SIZE);
+  .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {

arch/tile/kernel/vmlinux.lds.S SECTIONS · line 72

Quoted 10 lines

arch/tile/kernel/vmlinux.lds.S +7 -0

+    VMLINUX_SYMBOL(_sinittext) = .;
+    INIT_TEXT
+#ifdef CONFIG_JUMP_LABEL  /* __jump_table may reference __exit text */
+    EXIT_TEXT
+#endif
+    VMLINUX_SYMBOL(_einittext) = .;
+  }
 
    /* Now we skip back to PAGE_OFFSET for the data. */
    . = (. - TEXT_OFFSET + PAGE_OFFSET);

Hi Chris,

Thanks for the patch. I can confirm that it resolves the following compilation issue:

.exit.text' referenced in section __jump_table' of fs/built-in.o:
defined in discarded section .exit.text' of fs/built-in.o .exit.text' referenced in section `__jump_table' of fs/built-in.o:
defined in discarded section `.exit.text' of fs/built-in.o

I was able to create the issue by simply adding a static_key_unlikely() branch to an __exit section that ends up being built-in (non-module).

So this issue is really independent of this patch series... Should I add your patch to my series when I re-post?