From: kernel test robot <lkp@intel.com>
To: Peter Xu <peterx@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: kbuild-all@lists.01.org, Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
David Hildenbrand <david@redhat.com>,
Hugh Dickins <hughd@google.com>,
Jerome Glisse <jglisse@redhat.com>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Alistair Popple <apopple@nvidia.com>,
peterx@redhat.com
Subject: Re: [PATCH v8 15/23] mm/hugetlb: Handle pte markers in page faults
Date: Wed, 6 Apr 2022 21:37:00 +0800 [thread overview]
Message-ID: <202204062154.2txNJyaf-lkp@intel.com> (raw)
In-Reply-To: <20220405014909.14761-1-peterx@redhat.com>
Hi Peter,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on hnaz-mm/master]
[cannot apply to arnd-asm-generic/master linus/master linux/master v5.18-rc1 next-20220406]
[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]
url: https://github.com/intel-lab-lkp/linux/commits/Peter-Xu/userfaultfd-wp-Support-shmem-and-hugetlbfs/20220405-100136
base: https://github.com/hnaz/linux-mm master
config: s390-randconfig-r044-20220406 (https://download.01.org/0day-ci/archive/20220406/202204062154.2txNJyaf-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 11.2.0
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/e7e7aaec811e2817cd169f0cc1d8f81bdf1f05c3
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Peter-Xu/userfaultfd-wp-Support-shmem-and-hugetlbfs/20220405-100136
git checkout e7e7aaec811e2817cd169f0cc1d8f81bdf1f05c3
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=s390 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
mm/hugetlb.c: In function 'hugetlb_fault':
>> mm/hugetlb.c:5678:13: error: implicit declaration of function 'huge_pte_none_mostly'; did you mean 'pte_none_mostly'? [-Werror=implicit-function-declaration]
5678 | if (huge_pte_none_mostly(entry)) {
| ^~~~~~~~~~~~~~~~~~~~
| pte_none_mostly
cc1: some warnings being treated as errors
vim +5678 mm/hugetlb.c
5616
5617 vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
5618 unsigned long address, unsigned int flags)
5619 {
5620 pte_t *ptep, entry;
5621 spinlock_t *ptl;
5622 vm_fault_t ret;
5623 u32 hash;
5624 pgoff_t idx;
5625 struct page *page = NULL;
5626 struct page *pagecache_page = NULL;
5627 struct hstate *h = hstate_vma(vma);
5628 struct address_space *mapping;
5629 int need_wait_lock = 0;
5630 unsigned long haddr = address & huge_page_mask(h);
5631
5632 ptep = huge_pte_offset(mm, haddr, huge_page_size(h));
5633 if (ptep) {
5634 /*
5635 * Since we hold no locks, ptep could be stale. That is
5636 * OK as we are only making decisions based on content and
5637 * not actually modifying content here.
5638 */
5639 entry = huge_ptep_get(ptep);
5640 if (unlikely(is_hugetlb_entry_migration(entry))) {
5641 migration_entry_wait_huge(vma, mm, ptep);
5642 return 0;
5643 } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry)))
5644 return VM_FAULT_HWPOISON_LARGE |
5645 VM_FAULT_SET_HINDEX(hstate_index(h));
5646 }
5647
5648 /*
5649 * Acquire i_mmap_rwsem before calling huge_pte_alloc and hold
5650 * until finished with ptep. This serves two purposes:
5651 * 1) It prevents huge_pmd_unshare from being called elsewhere
5652 * and making the ptep no longer valid.
5653 * 2) It synchronizes us with i_size modifications during truncation.
5654 *
5655 * ptep could have already be assigned via huge_pte_offset. That
5656 * is OK, as huge_pte_alloc will return the same value unless
5657 * something has changed.
5658 */
5659 mapping = vma->vm_file->f_mapping;
5660 i_mmap_lock_read(mapping);
5661 ptep = huge_pte_alloc(mm, vma, haddr, huge_page_size(h));
5662 if (!ptep) {
5663 i_mmap_unlock_read(mapping);
5664 return VM_FAULT_OOM;
5665 }
5666
5667 /*
5668 * Serialize hugepage allocation and instantiation, so that we don't
5669 * get spurious allocation failures if two CPUs race to instantiate
5670 * the same page in the page cache.
5671 */
5672 idx = vma_hugecache_offset(h, vma, haddr);
5673 hash = hugetlb_fault_mutex_hash(mapping, idx);
5674 mutex_lock(&hugetlb_fault_mutex_table[hash]);
5675
5676 entry = huge_ptep_get(ptep);
5677 /* PTE markers should be handled the same way as none pte */
> 5678 if (huge_pte_none_mostly(entry)) {
5679 ret = hugetlb_no_page(mm, vma, mapping, idx, address, ptep,
5680 entry, flags);
5681 goto out_mutex;
5682 }
5683
5684 ret = 0;
5685
5686 /*
5687 * entry could be a migration/hwpoison entry at this point, so this
5688 * check prevents the kernel from going below assuming that we have
5689 * an active hugepage in pagecache. This goto expects the 2nd page
5690 * fault, and is_hugetlb_entry_(migration|hwpoisoned) check will
5691 * properly handle it.
5692 */
5693 if (!pte_present(entry))
5694 goto out_mutex;
5695
5696 /*
5697 * If we are going to COW/unshare the mapping later, we examine the
5698 * pending reservations for this page now. This will ensure that any
5699 * allocations necessary to record that reservation occur outside the
5700 * spinlock. For private mappings, we also lookup the pagecache
5701 * page now as it is used to determine if a reservation has been
5702 * consumed.
5703 */
5704 if ((flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) &&
5705 !huge_pte_write(entry)) {
5706 if (vma_needs_reservation(h, vma, haddr) < 0) {
5707 ret = VM_FAULT_OOM;
5708 goto out_mutex;
5709 }
5710 /* Just decrements count, does not deallocate */
5711 vma_end_reservation(h, vma, haddr);
5712
5713 if (!(vma->vm_flags & VM_MAYSHARE))
5714 pagecache_page = hugetlbfs_pagecache_page(h,
5715 vma, haddr);
5716 }
5717
5718 ptl = huge_pte_lock(h, mm, ptep);
5719
5720 /* Check for a racing update before calling hugetlb_wp() */
5721 if (unlikely(!pte_same(entry, huge_ptep_get(ptep))))
5722 goto out_ptl;
5723
5724 /* Handle userfault-wp first, before trying to lock more pages */
5725 if (userfaultfd_wp(vma) && huge_pte_uffd_wp(huge_ptep_get(ptep)) &&
5726 (flags & FAULT_FLAG_WRITE) && !huge_pte_write(entry)) {
5727 struct vm_fault vmf = {
5728 .vma = vma,
5729 .address = haddr,
5730 .real_address = address,
5731 .flags = flags,
5732 };
5733
5734 spin_unlock(ptl);
5735 if (pagecache_page) {
5736 unlock_page(pagecache_page);
5737 put_page(pagecache_page);
5738 }
5739 mutex_unlock(&hugetlb_fault_mutex_table[hash]);
5740 i_mmap_unlock_read(mapping);
5741 return handle_userfault(&vmf, VM_UFFD_WP);
5742 }
5743
5744 /*
5745 * hugetlb_wp() requires page locks of pte_page(entry) and
5746 * pagecache_page, so here we need take the former one
5747 * when page != pagecache_page or !pagecache_page.
5748 */
5749 page = pte_page(entry);
5750 if (page != pagecache_page)
5751 if (!trylock_page(page)) {
5752 need_wait_lock = 1;
5753 goto out_ptl;
5754 }
5755
5756 get_page(page);
5757
5758 if (flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) {
5759 if (!huge_pte_write(entry)) {
5760 ret = hugetlb_wp(mm, vma, address, ptep, flags,
5761 pagecache_page, ptl);
5762 goto out_put_page;
5763 } else if (likely(flags & FAULT_FLAG_WRITE)) {
5764 entry = huge_pte_mkdirty(entry);
5765 }
5766 }
5767 entry = pte_mkyoung(entry);
5768 if (huge_ptep_set_access_flags(vma, haddr, ptep, entry,
5769 flags & FAULT_FLAG_WRITE))
5770 update_mmu_cache(vma, haddr, ptep);
5771 out_put_page:
5772 if (page != pagecache_page)
5773 unlock_page(page);
5774 put_page(page);
5775 out_ptl:
5776 spin_unlock(ptl);
5777
5778 if (pagecache_page) {
5779 unlock_page(pagecache_page);
5780 put_page(pagecache_page);
5781 }
5782 out_mutex:
5783 mutex_unlock(&hugetlb_fault_mutex_table[hash]);
5784 i_mmap_unlock_read(mapping);
5785 /*
5786 * Generally it's safe to hold refcount during waiting page lock. But
5787 * here we just wait to defer the next page fault to avoid busy loop and
5788 * the page is not used after unlocked before returning from the current
5789 * page fault. So we are safe from accessing freed page, even if we wait
5790 * here without taking refcount.
5791 */
5792 if (need_wait_lock)
5793 wait_on_page_locked(page);
5794 return ret;
5795 }
5796
--
0-DAY CI Kernel Test Service
https://01.org/lkp
next prev parent reply other threads:[~2022-04-06 16:07 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 1:46 [PATCH v8 00/23] userfaultfd-wp: Support shmem and hugetlbfs Peter Xu
2022-04-05 1:46 ` [PATCH v8 01/23] mm: Introduce PTE_MARKER swap entry Peter Xu
2022-04-12 1:07 ` Alistair Popple
2022-04-12 19:45 ` Peter Xu
2022-04-13 0:30 ` Alistair Popple
2022-04-13 13:44 ` Peter Xu
2022-04-19 8:25 ` Alistair Popple
2022-04-19 19:44 ` Peter Xu
2022-04-05 1:48 ` [PATCH v8 02/23] mm: Teach core mm about pte markers Peter Xu
2022-04-12 1:22 ` Alistair Popple
2022-04-12 19:53 ` Peter Xu
2022-04-05 1:48 ` [PATCH v8 03/23] mm: Check against orig_pte for finish_fault() Peter Xu
2022-04-12 2:05 ` Alistair Popple
2022-04-12 19:54 ` Peter Xu
[not found] ` <CGME20220413140330eucas1p167da41e079712b829ef8237dc27b049c@eucas1p1.samsung.com>
2022-04-13 14:03 ` Marek Szyprowski
2022-04-13 16:43 ` Peter Xu
2022-04-14 7:51 ` Marek Szyprowski
2022-04-14 16:30 ` Peter Xu
2022-04-14 20:57 ` Andrew Morton
2022-04-14 21:08 ` Peter Xu
2022-04-15 14:21 ` Guenter Roeck
2022-04-15 14:41 ` Peter Xu
2022-04-05 1:48 ` [PATCH v8 04/23] mm/uffd: PTE_MARKER_UFFD_WP Peter Xu
2022-04-06 1:41 ` kernel test robot
2022-04-05 1:48 ` [PATCH v8 05/23] mm/shmem: Take care of UFFDIO_COPY_MODE_WP Peter Xu
2022-04-05 1:48 ` [PATCH v8 06/23] mm/shmem: Handle uffd-wp special pte in page fault handler Peter Xu
2022-05-11 16:30 ` David Hildenbrand
2022-05-12 16:34 ` Peter Xu
2022-04-05 1:48 ` [PATCH v8 07/23] mm/shmem: Persist uffd-wp bit across zapping for file-backed Peter Xu
2022-04-05 1:48 ` [PATCH v8 08/23] mm/shmem: Allow uffd wr-protect none pte for file-backed mem Peter Xu
2022-04-05 1:48 ` [PATCH v8 09/23] mm/shmem: Allows file-back mem to be uffd wr-protected on thps Peter Xu
2022-04-05 1:48 ` [PATCH v8 10/23] mm/shmem: Handle uffd-wp during fork() Peter Xu
2022-04-06 6:16 ` kernel test robot
2022-04-06 12:18 ` Peter Xu
2022-04-06 12:18 ` Peter Xu
2022-04-05 1:48 ` [PATCH v8 11/23] mm/hugetlb: Introduce huge pte version of uffd-wp helpers Peter Xu
2022-04-05 1:49 ` [PATCH v8 12/23] mm/hugetlb: Hook page faults for uffd write protection Peter Xu
2022-04-05 1:49 ` [PATCH v8 13/23] mm/hugetlb: Take care of UFFDIO_COPY_MODE_WP Peter Xu
2022-04-05 1:49 ` [PATCH v8 14/23] mm/hugetlb: Handle UFFDIO_WRITEPROTECT Peter Xu
2022-04-05 1:49 ` [PATCH v8 15/23] mm/hugetlb: Handle pte markers in page faults Peter Xu
2022-04-06 13:37 ` kernel test robot [this message]
2022-04-06 15:02 ` Peter Xu
2022-04-06 15:02 ` Peter Xu
2022-04-05 1:49 ` [PATCH v8 16/23] mm/hugetlb: Allow uffd wr-protect none ptes Peter Xu
2022-04-05 1:49 ` [PATCH v8 17/23] mm/hugetlb: Only drop uffd-wp special pte if required Peter Xu
2022-04-05 1:49 ` [PATCH v8 18/23] mm/hugetlb: Handle uffd-wp during fork() Peter Xu
2022-04-05 1:49 ` [PATCH v8 19/23] mm/khugepaged: Don't recycle vma pgtable if uffd-wp registered Peter Xu
2022-04-05 1:49 ` [PATCH v8 20/23] mm/pagemap: Recognize uffd-wp bit for shmem/hugetlbfs Peter Xu
2022-04-05 1:49 ` [PATCH v8 21/23] mm/uffd: Enable write protection for shmem & hugetlbfs Peter Xu
2022-04-05 1:49 ` [PATCH v8 22/23] mm: Enable PTE markers by default Peter Xu
2022-04-19 15:13 ` Johannes Weiner
2022-04-19 19:59 ` Peter Xu
2022-04-19 20:14 ` Johannes Weiner
2022-04-19 20:28 ` Peter Xu
2022-04-19 21:24 ` Johannes Weiner
2022-04-19 22:01 ` Peter Xu
2022-04-20 13:46 ` Johannes Weiner
2022-04-20 14:25 ` Peter Xu
2022-04-05 1:49 ` [PATCH v8 23/23] selftests/uffd: Enable uffd-wp for shmem/hugetlbfs Peter Xu
2022-04-05 22:16 ` [PATCH v8 00/23] userfaultfd-wp: Support shmem and hugetlbfs Andrew Morton
2022-04-05 22:42 ` Peter Xu
2022-04-05 22:49 ` Andrew Morton
2022-04-05 23:02 ` Peter Xu
2022-04-05 23:08 ` Andrew Morton
2022-05-10 19:05 ` Andrew Morton
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=202204062154.2txNJyaf-lkp@intel.com \
--to=lkp@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jglisse@redhat.com \
--cc=kbuild-all@lists.01.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=nadav.amit@gmail.com \
--cc=peterx@redhat.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.