rust/Kconfig: disable Rust support if CONFIG_MODVERSIONS=y #379
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In recent weeks, there have been a few reports of Rust build errors for defconfigs which have CONFIG_MODVERSIONS=y. See torvalds#378 for example. According to torvalds#59, Rust-for-Linux currently doesn't support MODVERSIONS. To prevent confusion and build errors in the future, disable Rust support if CONFIG_MODVERSIONS=y. Signed-off-by: Sven Van Asbroeck <[email protected]>
|
Review of
|
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jan 11, 2023
Currently modversion uses a fixed size array of size (64 - sizeof(long))
to store symbol names, thus placing a hard limit on length of symbols.
Rust symbols (which encodes crate and module names) can be quite a bit
longer. The length limit in kallsyms is increased to 512 for this reason.
It's a waste of space to simply expand the fixed array size to 512 in
modversion info entries. I therefore make it variably sized, with offset
to the next entry indicated by the initial "next" field.
In addition to supporting longer-than-56/60 byte symbols, this patch also
reduce the size for short symbols by getting rid of excessive 0 paddings.
There are still some zero paddings to ensure "next" and "crc" fields are
properly aligned.
This patch does have a tiny drawback that it makes ".mod.c" files generated
a bit less easy to read, as code like
"\x08\x00\x00\x00\x78\x56\x34\x12"
"symbol\0\0"
is generated as opposed to
{ 0x12345678, "symbol" },
because the structure is now variable-length. But hopefully nobody reads
the generated file :)
Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512")
Link: Rust-for-Linux#379
Signed-off-by: Gary Guo <[email protected]>
tobhe
pushed a commit
to UbuntuAsahi/linux
that referenced
this pull request
May 15, 2023
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
tobhe
pushed a commit
to UbuntuAsahi/linux
that referenced
this pull request
Jun 12, 2023
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
Joshua-Riek
pushed a commit
to Joshua-Riek/linux
that referenced
this pull request
Oct 24, 2023
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
arighi
pushed a commit
to arighi/sched_ext
that referenced
this pull request
Jan 10, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
arighi
pushed a commit
to arighi/sched_ext
that referenced
this pull request
Jan 25, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
arighi
pushed a commit
to arighi/sched_ext
that referenced
this pull request
Feb 4, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
arighi
pushed a commit
to arighi/sched_ext
that referenced
this pull request
Feb 7, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
arighi
pushed a commit
to arighi/sched_ext
that referenced
this pull request
Feb 7, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
JohnAZoidberg
pushed a commit
to FrameworkComputer/linux
that referenced
this pull request
Jun 1, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
ojeda
pushed a commit
that referenced
this pull request
Jul 29, 2024
The following splat is easy to reproduce upstream as well as in -stable kernels. Florian Westphal provided the following commit: d1dab4f ("net: add and use __skb_get_hash_symmetric_net") but this complementary fix has been also suggested by Willem de Bruijn and it can be easily backported to -stable kernel which consists in using DEBUG_NET_WARN_ON_ONCE instead to silence the following splat given __skb_get_hash() is used by the nftables tracing infrastructure to to identify packets in traces. [69133.561393] ------------[ cut here ]------------ [69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0 [69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0 [69133.562040] Call Trace: [69133.562044] <IRQ> [69133.562049] ? __warn+0x9f/0x1a0 [ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860 [...] [ 1211.841496] ? bpf_flow_dissect+0x160/0x160 [ 1211.841753] __skb_get_hash+0x97/0x280 [ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230 [ 1211.841776] ? mod_find+0xbf/0xe0 [ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0 [ 1211.841798] ? bpf_ksym_find+0x56/0xe0 [ 1211.841807] ? __rcu_read_unlock+0x2a/0x70 [ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables] [ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables] [ 1211.841964] ? get_stack_info+0x2b/0x80 [ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables] [ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables] Fixes: 9b52e3f ("flow_dissector: handle no-skb use case") Suggested-by: Willem de Bruijn <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
tuxedo-bot
pushed a commit
to tuxedocomputers/linux
that referenced
this pull request
Aug 29, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
tuxedo-bot
pushed a commit
to tuxedocomputers/linux
that referenced
this pull request
Sep 5, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
tuxedo-bot
pushed a commit
to tuxedocomputers/linux
that referenced
this pull request
Sep 11, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
tuxedo-bot
pushed a commit
to tuxedocomputers/linux
that referenced
this pull request
Sep 17, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
Fraxoor
pushed a commit
to Fraxoor/ubuntu_ava
that referenced
this pull request
Nov 15, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
Fraxoor
pushed a commit
to Fraxoor/ubuntu_ava
that referenced
this pull request
Nov 15, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux/linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
jglathe
pushed a commit
to jglathe/linux_ms_dev_kit
that referenced
this pull request
Dec 5, 2024
BugLink: https://bugs.launchpad.net/bugs/2007654 Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit in kallsyms is increased to 512 for this reason. It's a waste of space to simply expand the fixed array size to 512 in modversion info entries. I therefore make it variably sized, with offset to the next entry indicated by the initial "next" field. In addition to supporting longer-than-56/60 byte symbols, this patch also reduce the size for short symbols by getting rid of excessive 0 paddings. There are still some zero paddings to ensure "next" and "crc" fields are properly aligned. This patch does have a tiny drawback that it makes ".mod.c" files generated a bit less easy to read, as code like "\x08\x00\x00\x00\x78\x56\x34\x12" "symbol\0\0" is generated as opposed to { 0x12345678, "symbol" }, because the structure is now variable-length. But hopefully nobody reads the generated file :) Link: b8a94bf ("kallsyms: increase maximum kernel symbol length to 512") Link: Rust-for-Linux#379 Signed-off-by: Gary Guo <[email protected]> (backported from https://lore.kernel.org/lkml/[email protected]/) [ fix build error on s390x: always use a variable with TO_NATIVE() ] [ add dummy NULL entry at the end of the modversion array ] Signed-off-by: Andrea Righi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In recent weeks, there have been a few reports of Rust build errors
for defconfigs which have CONFIG_MODVERSIONS=y. See #378 for example.
According to #59, Rust-for-Linux currently doesn't support MODVERSIONS.
To prevent confusion and build errors in the future, disable Rust
support if CONFIG_MODVERSIONS=y.
Signed-off-by: Sven Van Asbroeck [email protected]