The patch titled Subject: buffer: add cast in grow_buffers() to avoid a multiplication libcall has been added to the -mm mm-unstable branch. Its filename is buffer-fix-grow_buffers-for-block-size-page_size-fix.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/buffer-fix-grow_buffers-for-block-size-page_size-fix.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Nathan Chancellor <nathan@xxxxxxxxxx> Subject: buffer: add cast in grow_buffers() to avoid a multiplication libcall Date: Tue, 28 Nov 2023 16:55:43 -0700 When building with clang after commit 697607935295 ("buffer: fix grow_buffers() for block size > PAGE_SIZE"), there is an error at link time due to the generation of a 128-bit multiplication libcall: ld.lld: error: undefined symbol: __muloti4 >>> referenced by buffer.c:0 (fs/buffer.c:0) >>> fs/buffer.o:(bdev_getblk) in archive vmlinux.a Due to the width mismatch between the factors and the sign mismatch between the factors and the result, clang generates IR that performs this overflow check with 65-bit signed multiplication and LLVM does not improve on it during optimization, so the 65-bit multiplication is extended to 128-bit during legalization, resulting in the libcall on most targets. To avoid the initial situation that causes clang to generate the problematic IR, cast size (which is an 'unsigned int') to the same type/width as block (which is currently a 'u64'/'unsigned long long'). GCC appears to already do this internally because there is no binary difference with the cast for arm, arm64, riscv, or x86_64. Link: https://github.com/ClangBuiltLinux/linux/issues/1958 Link: https://github.com/llvm/llvm-project/issues/38013 Link: https://lkml.kernel.org/r/20231128-avoid-muloti4-grow_buffers-v1-1-bc3d0f0ec483@xxxxxxxxxx Signed-off-by: Nathan Chancellor <nathan@xxxxxxxxxx> Reported-by: Naresh Kamboju <naresh.kamboju@xxxxxxxxxx> Closes: https://lore.kernel.org/CA+G9fYuA_PTd7R2NsBvtNb7qjwp4avHpCmWi4=OmY4jndDcQYA@xxxxxxxxxxxxxx/ Cc: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- fs/buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/buffer.c~buffer-fix-grow_buffers-for-block-size-page_size-fix +++ a/fs/buffer.c @@ -1091,7 +1091,7 @@ static bool grow_buffers(struct block_de * Check for a block which lies outside our maximum possible * pagecache index. */ - if (check_mul_overflow(block, size, &pos) || pos > MAX_LFS_FILESIZE) { + if (check_mul_overflow(block, (sector_t)size, &pos) || pos > MAX_LFS_FILESIZE) { printk(KERN_ERR "%s: requested out-of-range block %llu for device %pg\n", __func__, (unsigned long long)block, bdev); _ Patches currently in -mm which might be from nathan@xxxxxxxxxx are buffer-fix-grow_buffers-for-block-size-page_size-fix.patch