public inbox for llvm@lists.linux.dev
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Yin Fengwei <fengwei.yin@intel.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH v4 1/5] rmap: move hugetlb try_to_unmap to dedicated function
Date: Tue, 14 Mar 2023 00:55:54 +0800	[thread overview]
Message-ID: <202303140016.q8dVJMP2-lkp@intel.com> (raw)
In-Reply-To: <20230313124526.1207490-2-fengwei.yin@intel.com>

Hi Yin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on linus/master v6.3-rc2 next-20230310]
[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/Yin-Fengwei/rmap-move-hugetlb-try_to_unmap-to-dedicated-function/20230313-204656
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20230313124526.1207490-2-fengwei.yin%40intel.com
patch subject: [PATCH v4 1/5] rmap: move hugetlb try_to_unmap to dedicated function
config: arm-buildonly-randconfig-r001-20230312 (https://download.01.org/0day-ci/archive/20230314/202303140016.q8dVJMP2-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project 67409911353323ca5edf2049ef0df54132fa1ca7)
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
        # install arm cross compiling tool for clang build
        # apt-get install binutils-arm-linux-gnueabi
        # https://github.com/intel-lab-lkp/linux/commit/c43d03caaff9b0b9a869fd2a9b8beed7bc833f2a
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Yin-Fengwei/rmap-move-hugetlb-try_to_unmap-to-dedicated-function/20230313-204656
        git checkout c43d03caaff9b0b9a869fd2a9b8beed7bc833f2a
        # 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=arm olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303140016.q8dVJMP2-lkp@intel.com/

All errors (new ones prefixed by >>):

>> mm/rmap.c:1513:6: error: call to undeclared function 'huge_pte_dirty'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
           if (huge_pte_dirty(pteval))
               ^
   1 error generated.


vim +/huge_pte_dirty +1513 mm/rmap.c

  1443	
  1444	static bool try_to_unmap_one_hugetlb(struct folio *folio,
  1445			struct vm_area_struct *vma, struct mmu_notifier_range range,
  1446			struct page_vma_mapped_walk pvmw, unsigned long address,
  1447			enum ttu_flags flags)
  1448	{
  1449		struct mm_struct *mm = vma->vm_mm;
  1450		pte_t pteval;
  1451		bool ret = true, anon = folio_test_anon(folio);
  1452	
  1453		/*
  1454		 * The try_to_unmap() is only passed a hugetlb page
  1455		 * in the case where the hugetlb page is poisoned.
  1456		 */
  1457		VM_BUG_ON_FOLIO(!folio_test_hwpoison(folio), folio);
  1458		/*
  1459		 * huge_pmd_unshare may unmap an entire PMD page.
  1460		 * There is no way of knowing exactly which PMDs may
  1461		 * be cached for this mm, so we must flush them all.
  1462		 * start/end were already adjusted in caller
  1463		 * (try_to_unmap_one) to cover this range.
  1464		 */
  1465		flush_cache_range(vma, range.start, range.end);
  1466	
  1467		/*
  1468		 * To call huge_pmd_unshare, i_mmap_rwsem must be
  1469		 * held in write mode.  Caller needs to explicitly
  1470		 * do this outside rmap routines.
  1471		 *
  1472		 * We also must hold hugetlb vma_lock in write mode.
  1473		 * Lock order dictates acquiring vma_lock BEFORE
  1474		 * i_mmap_rwsem.  We can only try lock here and fail
  1475		 * if unsuccessful.
  1476		 */
  1477		if (!anon) {
  1478			VM_BUG_ON(!(flags & TTU_RMAP_LOCKED));
  1479			if (!hugetlb_vma_trylock_write(vma)) {
  1480				ret = false;
  1481				goto out;
  1482			}
  1483			if (huge_pmd_unshare(mm, vma, address, pvmw.pte)) {
  1484				hugetlb_vma_unlock_write(vma);
  1485				flush_tlb_range(vma,
  1486						range.start, range.end);
  1487				mmu_notifier_invalidate_range(mm,
  1488						range.start, range.end);
  1489				/*
  1490				 * The ref count of the PMD page was
  1491				 * dropped which is part of the way map
  1492				 * counting is done for shared PMDs.
  1493				 * Return 'true' here.  When there is
  1494				 * no other sharing, huge_pmd_unshare
  1495				 * returns false and we will unmap the
  1496				 * actual page and drop map count
  1497				 * to zero.
  1498				 */
  1499				goto out;
  1500			}
  1501			hugetlb_vma_unlock_write(vma);
  1502		}
  1503		pteval = huge_ptep_clear_flush(vma, address, pvmw.pte);
  1504	
  1505		/*
  1506		 * Now the pte is cleared. If this pte was uffd-wp armed,
  1507		 * we may want to replace a none pte with a marker pte if
  1508		 * it's file-backed, so we don't lose the tracking info.
  1509		 */
  1510		pte_install_uffd_wp_if_needed(vma, address, pvmw.pte, pteval);
  1511	
  1512		/* Set the dirty flag on the folio now the pte is gone. */
> 1513		if (huge_pte_dirty(pteval))
  1514			folio_mark_dirty(folio);
  1515	
  1516		/* Update high watermark before we lower rss */
  1517		update_hiwater_rss(mm);
  1518	
  1519		/* Poisoned hugetlb folio with TTU_HWPOISON always cleared in flags */
  1520		pteval = swp_entry_to_pte(make_hwpoison_entry(&folio->page));
  1521		set_huge_pte_at(mm, address, pvmw.pte, pteval);
  1522		hugetlb_count_sub(folio_nr_pages(folio), mm);
  1523	
  1524		/*
  1525		 * No need to call mmu_notifier_invalidate_range() it has be
  1526		 * done above for all cases requiring it to happen under page
  1527		 * table lock before mmu_notifier_invalidate_range_end()
  1528		 *
  1529		 * See Documentation/mm/mmu_notifier.rst
  1530		 */
  1531		page_remove_rmap(&folio->page, vma, true);
  1532		/* No VM_LOCKED set in vma->vm_flags for hugetlb. So not
  1533		 * necessary to call mlock_drain_local().
  1534		 */
  1535		folio_put(folio);
  1536	
  1537	out:
  1538		return ret;
  1539	}
  1540	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests

       reply	other threads:[~2023-03-13 16:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230313124526.1207490-2-fengwei.yin@intel.com>
2023-03-13 16:55 ` kernel test robot [this message]
2023-03-13 17:37 ` [PATCH v4 1/5] rmap: move hugetlb try_to_unmap to dedicated function kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202303140016.q8dVJMP2-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=fengwei.yin@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox