Hi Nathan, On Mon, 13 Nov 2023 at 22:50, Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > > On Mon, Nov 13, 2023 at 09:10:06AM -0800, Andrew Morton wrote: > > On Sun, 12 Nov 2023 12:52:00 +0800 kernel test robot <lkp@xxxxxxxxx> wrote: > > > > > Hi Matthew, > > > > > > kernel test robot noticed the following build errors: > > > > > > [auto build test ERROR on akpm-mm/mm-everything] > > > [also build test ERROR on linus/master next-20231110] > > > [cannot apply to v6.6] > > > [If your patch is applied to the wrong git tree, kindly drop us a note. > > > And when submitting patch, we suggest to use '--base' as documented in > > > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > > > > > url: https://github.com/intel-lab-lkp/linux/commits/Matthew-Wilcox-Oracle/buffer-Return-bool-from-grow_dev_folio/20231110-051651 > > > base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything > > > patch link: https://lore.kernel.org/r/20231109210608.2252323-4-willy%40infradead.org > > > patch subject: [PATCH v2 3/7] buffer: Fix grow_buffers() for block size > PAGE_SIZE > > > config: hexagon-comet_defconfig (https://download.01.org/0day-ci/archive/20231112/202311121240.AN8GbAbe-lkp@xxxxxxxxx/config) > > > compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07) > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231112/202311121240.AN8GbAbe-lkp@xxxxxxxxx/reproduce) > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > > the same patch/commit), kindly add following tags > > > | Reported-by: kernel test robot <lkp@xxxxxxxxx> > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202311121240.AN8GbAbe-lkp@xxxxxxxxx/ KFT CI also have been noticing this build problem on Linux next. Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx> > > > > > > All errors (new ones prefixed by >>): > > > > > > >> ld.lld: error: undefined symbol: __muloti4 > > > >>> referenced by buffer.c > > > >>> fs/buffer.o:(bdev_getblk) in archive vmlinux.a > > > >>> referenced by buffer.c > > > >>> fs/buffer.o:(bdev_getblk) in archive vmlinux.a > > > > > > > What a peculiar compiler. > > > > I assume this fixes? > > > > --- a/fs/buffer.c~buffer-fix-grow_buffers-for-block-size-page_size-fix > > +++ a/fs/buffer.c > > @@ -1099,7 +1099,7 @@ static bool grow_buffers(struct block_de > > } > > > > /* Create a folio with the proper size buffers */ > > - return grow_dev_folio(bdev, block, pos / PAGE_SIZE, size, gfp); > > + return grow_dev_folio(bdev, block, pos >> PAGE_SHIFT, size, gfp); > > } > > > > static struct buffer_head * > > _ > > > > > > No, this is not a division libcall. This seems to be related to the > types of the variables used in __builtin_mul_overflow() :/ for some odd > reason, clang generates a libcall when passing in an 'unsigned long > long' and 'unsigned int', which apparently has not been done before in > the kernel? > > https://github.com/ClangBuiltLinux/linux/issues/1958 > https://godbolt.org/z/csfGc6z6c > > A cast would work around this but that could have other implications I > am not aware of (I've done little further investigation due to LPC): Thanks for providing this fix patch. > diff --git a/fs/buffer.c b/fs/buffer.c > index 4eb44ccdc6be..d39934783743 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -1091,7 +1091,7 @@ static bool grow_buffers(struct block_device *bdev, sector_t block, > * 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, (u64)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); > > Cheers, > Nathan - Naresh
