| 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
| ||
|
Message-ID: <202209050027.b6h4HE6N-lkp@intel.com>
Date: Mon, 5 Sep 2022 01:00:00 +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: 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-a005 (https://download.01.org/0day-ci/archive/20220905/202209050027.b6h4HE6N-lkp@intel.com/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@...el.com>
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
Powered by blists - more mailing lists