Re: [PATCH] mm: use mem_map_offset instead of mem_map_next

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Cheng,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on akpm-mm/mm-everything]

url:    https://github.com/intel-lab-lkp/linux/commits/Cheng-Li/mm-use-mem_map_offset-instead-of-mem_map_next/20220904-220520
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
config: i386-randconfig-a005 (https://download.01.org/0day-ci/archive/20220905/202209050027.b6h4HE6N-lkp@xxxxxxxxx/config)
compiler: gcc-11 (Debian 11.3.0-5) 11.3.0
reproduce (this is a W=1 build):
        # https://github.com/intel-lab-lkp/linux/commit/18a9446796efe2ae164f38013cbd4272a6b89cb1
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Cheng-Li/mm-use-mem_map_offset-instead-of-mem_map_next/20220904-220520
        git checkout 18a9446796efe2ae164f38013cbd4272a6b89cb1
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@xxxxxxxxx>

All error/warnings (new ones prefixed by >>):

   mm/hugetlb.c: In function '__prep_compound_gigantic_page':
>> mm/hugetlb.c:1798:39: warning: passing argument 2 of 'mem_map_offset' makes integer from pointer without a cast [-Wint-conversion]
    1798 |                 p = mem_map_offset(p, page, i);
         |                                       ^~~~
         |                                       |
         |                                       struct page *
   In file included from mm/hugetlb.c:47:
   mm/internal.h:646:66: note: expected 'int' but argument is of type 'struct page *'
     646 | static inline struct page *mem_map_offset(struct page *base, int offset)
         |                                                              ~~~~^~~~~~
>> mm/hugetlb.c:1798:21: error: too many arguments to function 'mem_map_offset'
    1798 |                 p = mem_map_offset(p, page, i);
         |                     ^~~~~~~~~~~~~~
   In file included from mm/hugetlb.c:47:
   mm/internal.h:646:28: note: declared here
     646 | static inline struct page *mem_map_offset(struct page *base, int offset)
         |                            ^~~~~~~~~~~~~~


vim +/mem_map_offset +1798 mm/hugetlb.c

  1785	
  1786	static bool __prep_compound_gigantic_page(struct page *page, unsigned int order,
  1787									bool demote)
  1788	{
  1789		int i, j;
  1790		int nr_pages = 1 << order;
  1791		struct page *p;
  1792	
  1793		/* we rely on prep_new_huge_page to set the destructor */
  1794		set_compound_order(page, order);
  1795		__ClearPageReserved(page);
  1796		__SetPageHead(page);
  1797		for (i = 1; i < nr_pages; i++) {
> 1798			p = mem_map_offset(p, page, i);
  1799	
  1800			/*
  1801			 * For gigantic hugepages allocated through bootmem at
  1802			 * boot, it's safer to be consistent with the not-gigantic
  1803			 * hugepages and clear the PG_reserved bit from all tail pages
  1804			 * too.  Otherwise drivers using get_user_pages() to access tail
  1805			 * pages may get the reference counting wrong if they see
  1806			 * PG_reserved set on a tail page (despite the head page not
  1807			 * having PG_reserved set).  Enforcing this consistency between
  1808			 * head and tail pages allows drivers to optimize away a check
  1809			 * on the head page when they need know if put_page() is needed
  1810			 * after get_user_pages().
  1811			 */
  1812			__ClearPageReserved(p);
  1813			/*
  1814			 * Subtle and very unlikely
  1815			 *
  1816			 * Gigantic 'page allocators' such as memblock or cma will
  1817			 * return a set of pages with each page ref counted.  We need
  1818			 * to turn this set of pages into a compound page with tail
  1819			 * page ref counts set to zero.  Code such as speculative page
  1820			 * cache adding could take a ref on a 'to be' tail page.
  1821			 * We need to respect any increased ref count, and only set
  1822			 * the ref count to zero if count is currently 1.  If count
  1823			 * is not 1, we return an error.  An error return indicates
  1824			 * the set of pages can not be converted to a gigantic page.
  1825			 * The caller who allocated the pages should then discard the
  1826			 * pages using the appropriate free interface.
  1827			 *
  1828			 * In the case of demote, the ref count will be zero.
  1829			 */
  1830			if (!demote) {
  1831				if (!page_ref_freeze(p, 1)) {
  1832					pr_warn("HugeTLB page can not be used due to unexpected inflated ref count\n");
  1833					goto out_error;
  1834				}
  1835			} else {
  1836				VM_BUG_ON_PAGE(page_count(p), p);
  1837			}
  1838			set_compound_head(p, page);
  1839		}
  1840		atomic_set(compound_mapcount_ptr(page), -1);
  1841		atomic_set(compound_pincount_ptr(page), 0);
  1842		return true;
  1843	
  1844	out_error:
  1845		/* undo tail page modifications made above */
  1846		for (j = 1; j < i; j++) {
  1847			p = mem_map_offset(page, j);
  1848			clear_compound_head(p);
  1849			set_page_refcounted(p);
  1850		}
  1851		/* need to clear PG_reserved on remaining tail pages  */
  1852		for (; j < nr_pages; j++) {
  1853			p = mem_map_offset(page, j);
  1854			__ClearPageReserved(p);
  1855		}
  1856		set_compound_order(page, 0);
  1857	#ifdef CONFIG_64BIT
  1858		page[1].compound_nr = 0;
  1859	#endif
  1860		__ClearPageHead(page);
  1861		return false;
  1862	}
  1863	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux