Re: [PATCH v2 3/5] iomap: Support large pages

kbuild test robot
2019-08-23T12:49:18Z

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Hi Matthew,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc5 next-20190823]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url: https://github.com/0day-ci/linux/commits/Matthew-Wilcox/iomap-xfs-support-for-large-pages/20190823-191138
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=c6x

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

In file included from include/linux/blkdev.h:16:0,
from include/linux/iomap.h:10,
from fs/iomap/buffered-io.c:9:
include/linux/pagemap.h: In function 'file_offset_of_next_page':
include/linux/pagemap.h:445:32: error: implicit declaration of function 'compound_nr'; did you mean 'compound_order'? [-Werror=implicit-function-declaration]
return ((loff_t)page->index + compound_nr(page)) << PAGE_SHIFT;
^~~~~~~~~~~
compound_order
include/linux/pagemap.h: In function 'i_blocks_per_page':
include/linux/pagemap.h:659:9: error: implicit declaration of function 'page_size'; did you mean 'page_zone'? [-Werror=implicit-function-declaration]
return page_size(page) >> inode->i_blkbits;
^~~~~~~~~
page_zone
fs/iomap/buffered-io.c: In function 'iomap_nr_vecs':
>> fs/iomap/buffered-io.c:213:43: error: implicit declaration of function 'page_shift'; did you mean 'page_pgdat'? [-Werror=implicit-function-declaration]
return (length + page_size(page) - 1) >> page_shift(page);
^~~~~~~~~~
page_pgdat
cc1: some warnings being treated as errors

vim +213 fs/iomap/buffered-io.c

205
206 /*
207 * Estimate the number of vectors we need based on the current page size;
208 * if we're wrong we'll end up doing an overly large allocation or needing
209 * to do a second allocation, neither of which is a big deal.
210 */
211 static unsigned int iomap_nr_vecs(struct page *page, loff_t length)
212 {
> 213 return (length + page_size(page) - 1) >> page_shift(page);
214 }
215

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49703 bytes --]