linux-kernel - Re: [PATCH] mm: use mem_map_offset instead of mem_map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202209050030.Qp5T7Hpc-lkp@intel.com>
Date:   Mon, 5 Sep 2022 00:38:11 +0800
From:   kernel test robot <lkp@...el.com>
To:     Cheng Li <lic121@...natelecom.cn>, mike.kravetz@...cle.com,
        akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Cc:     llvm@...ts.linux.dev, kbuild-all@...ts.01.org,
        Cheng Li <lic121@...natelecom.cn>
Subject: Re: [PATCH] mm: use mem_map_offset instead of mem_map_next

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-a002
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # 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
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 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@...el.com>

All errors (new ones prefixed by >>):

>> mm/hugetlb.c:1798:31: error: too many arguments to function call, expected 2, have 3
                   p = mem_map_offset(p, page, i);
                       ~~~~~~~~~~~~~~          ^
   mm/internal.h:646:28: note: 'mem_map_offset' declared here
   static inline struct page *mem_map_offset(struct page *base, int offset)
                              ^
   1 error generated.


vim +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

View attachment "config" of type "text/plain" (164331 bytes)