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
