From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Khorenko Date: Fri, 21 Aug 2026 18:42:31 +0200 Subject: [Devel] [PATCH RHEL10 COMMIT] ext4: select LIBCRC32C In-Reply-To: <20260821163718.187766-32-khorenko@virtuozzo.com> Message-ID: <202608211642.67LGgVAN668621@f0.sw.ru> List-Id: The commit is pushed to "branch-rh10-6.12.0-211.39.1.16.x.vz10-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git after rh10-6.12.0-211.39.1.16.6.vz10 ------> commit ff1034933e199cca8a40e9156ba2cc49df80a62b Author: Konstantin Khorenko Date: Fri Aug 21 18:37:17 2026 +0200 ext4: select LIBCRC32C ext4 computes its metadata checksums with crc32c(). Upstream that helper moved into lib/crc32.c under CONFIG_CRC32, which is what ext4 selects, but this tree still has the older layout where it lives in lib/libcrc32c.c under CONFIG_LIBCRC32C - the RHEL10.2 base carries the ext4 side of the conversion and not the lib one. So a kernel with ext4 built in and nothing else pulling libcrc32c in does not link: ld: vmlinux.o: in function 'ext4_inode_bitmap_csum_verify': undefined reference to 'crc32c' Our configs get away with it because other filesystems select CONFIG_LIBCRC32C; plain x86_64 defconfig, which we now want to keep building, does not. Select it explicitly until the lib side is caught up with upstream, where this select becomes redundant rather than wrong. Fixes: 9f055df11343 ("rh10: import RHEL10 kernel-6.12.0-211.16.1.el10") Feature: fix ms/ext4 https://virtuozzo.atlassian.net/browse/VSTOR-134732 Signed-off-by: Konstantin Khorenko --- fs/ext4/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig index c9ca41d91a6c1..8849d297102d5 100644 --- a/fs/ext4/Kconfig +++ b/fs/ext4/Kconfig @@ -32,6 +32,7 @@ config EXT4_FS select JBD2 select CRC16 select CRC32 + select LIBCRC32C select FS_IOMAP select FS_ENCRYPTION_ALGS if FS_ENCRYPTION help