linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Askar Safin <safinaskar@gmail.com>
To: ebiggers@kernel.org
Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-mips@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
	linux-crypto@vger.kernel.org, loongarch@lists.linux.dev,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-ext4@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	ardb@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [f2fs-dev] [PATCH v4 15/19] lib/crc32: make crc32c() go directly to lib
Date: Sun, 19 Oct 2025 09:08:45 +0300	[thread overview]
Message-ID: <20251019060845.553414-1-safinaskar@gmail.com> (raw)
In-Reply-To: <20241202010844.144356-16-ebiggers@kernel.org>

Eric Biggers <ebiggers@kernel.org>:
> Now that the lower level __crc32c_le() library function is optimized for

This patch (i. e. 38a9a5121c3b ("lib/crc32: make crc32c() go directly to lib"))
solves actual bug I found in practice. So, please, backport it
to stable kernels.

I did bisect.

It is possible to apply this patch on top of v6.12.48 without conflicts.

The bug actually prevents me for using my system (more details below).

Here is steps to reproduce bug I noticed.

Build kernel so:

$ cat /tmp/mini
CONFIG_64BIT=y
CONFIG_PRINTK=y
CONFIG_SERIAL_8250=y
CONFIG_TTY=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_DEVTMPFS=y
CONFIG_MODULES=y
CONFIG_BTRFS_FS=m
CONFIG_MODULE_COMPRESS=y
CONFIG_MODULE_COMPRESS_XZ=y
CONFIG_MODULE_COMPRESS_ALL=y
CONFIG_MODULE_DECOMPRESS=y
CONFIG_PRINTK_TIME=y
$ make allnoconfig KCONFIG_ALLCONFIG=/tmp/mini
$ make

Then create initramfs, which contains statically built busybox
(I used busybox v1.37.0 (Debian 1:1.37.0-6+b3)) and modules we just created.

Then run Qemu using command line similar to this:

qemu-system-x86_64 -kernel arch/x86/boot/bzImage -initrd i.gz -append 'console=ttyS0 panic=1 rdinit=/bin/busybox sh' -m 256 -no-reboot -enable-kvm -serial stdio -display none

Then in busybox shell type this:

# mkdir /proc
# busybox mount -t proc proc /proc
# modprobe btrfs

On buggy kernels I get this output:

# modprobe btrfs
[   19.614228] raid6: skipped pq benchmark and selected sse2x4
[   19.614638] raid6: using intx1 recovery algorithm
[   19.616569] xor: measuring software checksum speed
[   19.616937]    prefetch64-sse  : 42616 MB/sec
[   19.617270]    generic_sse     : 41320 MB/sec
[   19.617531] xor: using function: prefetch64-sse (42616 MB/sec)
[   19.619731] Invalid ELF header magic: != ELF
modprobe: can't load module libcrc32c (kernel/lib/libcrc32c.ko.xz): unknown symbol in module, or unknown parameter

The bug is reproducible on all kernels from v6.12 until this commit.
And it is not reproducible on all kernels, which contain this commit.
I found this using bisect.

This bug actually breaks my workflow. I have btrfs as root filesystem.
Initramfs, generated by Debian, doesn't suit my needs. So I'm going
to create my own initramfs from scratch. (Note that I use Debian Trixie,
which has v6.12.48 kernel.) During testing this initramfs in Qemu
I noticed that command "modprobe btrfs" fails with error given above.
(I not yet tried to test this initramfs on real hardware.)

So, this bug actually breaks my workflow.

So, please backport this patch (i. e. 38a9a5121c3b ("lib/crc32: make crc32c() go directly to lib"))
to stable kernels.

I tested that this patch can be applied without conflicts on top of v6.12.48,
and this patch indeed fixes the bug for v6.12.48.

If you want, I can give more info.

It is possible that this is in fact bug in busybox, not in Linux.
But still I think that backporting this patch is good idea.

This busybox thread my be related:
https://lists.busybox.net/pipermail/busybox/2023-May/090309.html

-- 
Askar Safin


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2025-10-19  6:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-02  1:08 [f2fs-dev] [PATCH v4 00/19] Wire up CRC32 library functions to arch-optimized code Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 01/19] lib/crc32: drop leading underscores from __crc32c_le_base Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 02/19] lib/crc32: improve support for arch-specific overrides Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 03/19] lib/crc32: expose whether the lib is really optimized at runtime Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 04/19] crypto: crc32 - don't unnecessarily register arch algorithms Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 05/19] arm/crc32: expose CRC32 functions through lib Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 06/19] loongarch/crc32: " Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 07/19] mips/crc32: " Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 08/19] powerpc/crc32: " Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 09/19] s390/crc32: " Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 10/19] sparc/crc32: " Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 11/19] x86/crc32: update prototype for crc_pcl() Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 12/19] x86/crc32: update prototype for crc32_pclmul_le_16() Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 13/19] x86/crc32: expose CRC32 functions through lib Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 14/19] bcachefs: Explicitly select CRYPTO from BCACHEFS_FS Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 15/19] lib/crc32: make crc32c() go directly to lib Eric Biggers via Linux-f2fs-devel
2025-10-19  6:08   ` Askar Safin [this message]
2025-10-19  8:10     ` Askar Safin
2025-10-19 16:23       ` Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 16/19] ext4: switch to using the crc32c library Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 17/19] jbd2: " Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 18/19] f2fs: switch to using the crc32 library Eric Biggers via Linux-f2fs-devel
2024-12-02  1:08 ` [f2fs-dev] [PATCH v4 19/19] scsi: target: iscsi: switch to using the crc32c library Eric Biggers via Linux-f2fs-devel
2024-12-12 21:37 ` [f2fs-dev] [PATCH v4 00/19] Wire up CRC32 library functions to arch-optimized code Eric Biggers via Linux-f2fs-devel
2025-01-29  0:56 ` patchwork-bot+f2fs--- via Linux-f2fs-devel

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=20251019060845.553414-1-safinaskar@gmail.com \
    --to=safinaskar@gmail.com \
    --cc=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=sparclinux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).