All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Pu Lehui <pulehui@huaweicloud.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [RFC PATCH v2 2/2] mm/mremap: Expose abnormal new_pte during move_ptes
Date: Wed, 28 May 2025 01:57:52 +0800	[thread overview]
Message-ID: <202505280152.hvGSNcAt-lkp@intel.com> (raw)
In-Reply-To: <20250527132351.2050820-3-pulehui@huaweicloud.com>

Hi Pu,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on linus/master v6.15 next-20250527]
[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/Pu-Lehui/mm-mremap-Fix-uprobe-anon-page-be-overwritten-when-expanding-vma-during-mremap/20250527-212250
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20250527132351.2050820-3-pulehui%40huaweicloud.com
patch subject: [RFC PATCH v2 2/2] mm/mremap: Expose abnormal new_pte during move_ptes
config: sparc-randconfig-001-20250528 (https://download.01.org/0day-ci/archive/20250528/202505280152.hvGSNcAt-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250528/202505280152.hvGSNcAt-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505280152.hvGSNcAt-lkp@intel.com/

All errors (new ones prefixed by >>):

   mm/mremap.c: In function 'move_ptes':
>> mm/mremap.c:242:17: error: expected ';' before 'if'
     242 |                 if (pte_none(ptep_get(old_pte)))
         |                 ^~


vim +242 mm/mremap.c

6dec97dc92946e Cyrill Gorcunov   2013-08-27  172  
664dc4da2694fa Lorenzo Stoakes   2025-03-10  173  static int move_ptes(struct pagetable_move_control *pmc,
664dc4da2694fa Lorenzo Stoakes   2025-03-10  174  		unsigned long extent, pmd_t *old_pmd, pmd_t *new_pmd)
^1da177e4c3f41 Linus Torvalds    2005-04-16  175  {
664dc4da2694fa Lorenzo Stoakes   2025-03-10  176  	struct vm_area_struct *vma = pmc->old;
0cef0bb836e3cf Ryan Roberts      2025-01-07  177  	bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma);
^1da177e4c3f41 Linus Torvalds    2005-04-16  178  	struct mm_struct *mm = vma->vm_mm;
7be7a546994f12 Hugh Dickins      2005-10-29  179  	pte_t *old_pte, *new_pte, pte;
838d02354464c3 Qi Zheng          2024-09-26  180  	pmd_t dummy_pmdval;
4c21e2f2441dc5 Hugh Dickins      2005-10-29  181  	spinlock_t *old_ptl, *new_ptl;
5d1904204c9959 Aaron Lu          2016-11-10  182  	bool force_flush = false;
664dc4da2694fa Lorenzo Stoakes   2025-03-10  183  	unsigned long old_addr = pmc->old_addr;
664dc4da2694fa Lorenzo Stoakes   2025-03-10  184  	unsigned long new_addr = pmc->new_addr;
664dc4da2694fa Lorenzo Stoakes   2025-03-10  185  	unsigned long old_end = old_addr + extent;
5d1904204c9959 Aaron Lu          2016-11-10  186  	unsigned long len = old_end - old_addr;
a5be621ee2925b Hugh Dickins      2023-06-08  187  	int err = 0;
^1da177e4c3f41 Linus Torvalds    2005-04-16  188  
^1da177e4c3f41 Linus Torvalds    2005-04-16  189  	/*
c8c06efa8b5526 Davidlohr Bueso   2014-12-12  190  	 * When need_rmap_locks is true, we take the i_mmap_rwsem and anon_vma
38a76013ad809b Michel Lespinasse 2012-10-08  191  	 * locks to ensure that rmap will always observe either the old or the
38a76013ad809b Michel Lespinasse 2012-10-08  192  	 * new ptes. This is the easiest way to avoid races with
38a76013ad809b Michel Lespinasse 2012-10-08  193  	 * truncate_pagecache(), page migration, etc...
38a76013ad809b Michel Lespinasse 2012-10-08  194  	 *
38a76013ad809b Michel Lespinasse 2012-10-08  195  	 * When need_rmap_locks is false, we use other ways to avoid
38a76013ad809b Michel Lespinasse 2012-10-08  196  	 * such races:
38a76013ad809b Michel Lespinasse 2012-10-08  197  	 *
38a76013ad809b Michel Lespinasse 2012-10-08  198  	 * - During exec() shift_arg_pages(), we use a specially tagged vma
222100eed264ba Anshuman Khandual 2020-04-01  199  	 *   which rmap call sites look for using vma_is_temporary_stack().
38a76013ad809b Michel Lespinasse 2012-10-08  200  	 *
38a76013ad809b Michel Lespinasse 2012-10-08  201  	 * - During mremap(), new_vma is often known to be placed after vma
38a76013ad809b Michel Lespinasse 2012-10-08  202  	 *   in rmap traversal order. This ensures rmap will always observe
38a76013ad809b Michel Lespinasse 2012-10-08  203  	 *   either the old pte, or the new pte, or both (the page table locks
38a76013ad809b Michel Lespinasse 2012-10-08  204  	 *   serialize access to individual ptes, but only rmap traversal
38a76013ad809b Michel Lespinasse 2012-10-08  205  	 *   order guarantees that we won't miss both the old and new ptes).
^1da177e4c3f41 Linus Torvalds    2005-04-16  206  	 */
664dc4da2694fa Lorenzo Stoakes   2025-03-10  207  	if (pmc->need_rmap_locks)
1d069b7dd56728 Hugh Dickins      2016-05-19  208  		take_rmap_locks(vma);
^1da177e4c3f41 Linus Torvalds    2005-04-16  209  
4c21e2f2441dc5 Hugh Dickins      2005-10-29  210  	/*
4c21e2f2441dc5 Hugh Dickins      2005-10-29  211  	 * We don't have to worry about the ordering of src and dst
c1e8d7c6a7a682 Michel Lespinasse 2020-06-08  212  	 * pte locks because exclusive mmap_lock prevents deadlock.
4c21e2f2441dc5 Hugh Dickins      2005-10-29  213  	 */
c74df32c724a16 Hugh Dickins      2005-10-29  214  	old_pte = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl);
a5be621ee2925b Hugh Dickins      2023-06-08  215  	if (!old_pte) {
a5be621ee2925b Hugh Dickins      2023-06-08  216  		err = -EAGAIN;
a5be621ee2925b Hugh Dickins      2023-06-08  217  		goto out;
a5be621ee2925b Hugh Dickins      2023-06-08  218  	}
838d02354464c3 Qi Zheng          2024-09-26  219  	/*
838d02354464c3 Qi Zheng          2024-09-26  220  	 * Now new_pte is none, so hpage_collapse_scan_file() path can not find
838d02354464c3 Qi Zheng          2024-09-26  221  	 * this by traversing file->f_mapping, so there is no concurrency with
838d02354464c3 Qi Zheng          2024-09-26  222  	 * retract_page_tables(). In addition, we already hold the exclusive
838d02354464c3 Qi Zheng          2024-09-26  223  	 * mmap_lock, so this new_pte page is stable, so there is no need to get
838d02354464c3 Qi Zheng          2024-09-26  224  	 * pmdval and do pmd_same() check.
838d02354464c3 Qi Zheng          2024-09-26  225  	 */
838d02354464c3 Qi Zheng          2024-09-26  226  	new_pte = pte_offset_map_rw_nolock(mm, new_pmd, new_addr, &dummy_pmdval,
838d02354464c3 Qi Zheng          2024-09-26  227  					   &new_ptl);
a5be621ee2925b Hugh Dickins      2023-06-08  228  	if (!new_pte) {
a5be621ee2925b Hugh Dickins      2023-06-08  229  		pte_unmap_unlock(old_pte, old_ptl);
a5be621ee2925b Hugh Dickins      2023-06-08  230  		err = -EAGAIN;
a5be621ee2925b Hugh Dickins      2023-06-08  231  		goto out;
a5be621ee2925b Hugh Dickins      2023-06-08  232  	}
4c21e2f2441dc5 Hugh Dickins      2005-10-29  233  	if (new_ptl != old_ptl)
f20dc5f7c1adf1 Ingo Molnar       2006-07-03  234  		spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
3ea277194daaea Mel Gorman        2017-08-02  235  	flush_tlb_batched_pending(vma->vm_mm);
6606c3e0da5360 Zachary Amsden    2006-09-30  236  	arch_enter_lazy_mmu_mode();
7be7a546994f12 Hugh Dickins      2005-10-29  237  
7be7a546994f12 Hugh Dickins      2005-10-29  238  	for (; old_addr < old_end; old_pte++, old_addr += PAGE_SIZE,
7be7a546994f12 Hugh Dickins      2005-10-29  239  				   new_pte++, new_addr += PAGE_SIZE) {
41d8ca0986951c Pu Lehui          2025-05-27  240  		WARN_ON_ONCE(!pte_none(*new_pte))
41d8ca0986951c Pu Lehui          2025-05-27  241  
c33c794828f212 Ryan Roberts      2023-06-12 @242  		if (pte_none(ptep_get(old_pte)))
7be7a546994f12 Hugh Dickins      2005-10-29  243  			continue;
5d1904204c9959 Aaron Lu          2016-11-10  244  
a2ce2666aa3509 Aaron Lu          2016-11-29  245  		pte = ptep_get_and_clear(mm, old_addr, old_pte);
5d1904204c9959 Aaron Lu          2016-11-10  246  		/*
eb66ae03082960 Linus Torvalds    2018-10-12  247  		 * If we are remapping a valid PTE, make sure
a2ce2666aa3509 Aaron Lu          2016-11-29  248  		 * to flush TLB before we drop the PTL for the
eb66ae03082960 Linus Torvalds    2018-10-12  249  		 * PTE.
a2ce2666aa3509 Aaron Lu          2016-11-29  250  		 *
eb66ae03082960 Linus Torvalds    2018-10-12  251  		 * NOTE! Both old and new PTL matter: the old one
a929e0d10f3db1 Kefeng Wang       2024-06-04  252  		 * for racing with folio_mkclean(), the new one to
eb66ae03082960 Linus Torvalds    2018-10-12  253  		 * make sure the physical page stays valid until
eb66ae03082960 Linus Torvalds    2018-10-12  254  		 * the TLB entry for the old mapping has been
eb66ae03082960 Linus Torvalds    2018-10-12  255  		 * flushed.
5d1904204c9959 Aaron Lu          2016-11-10  256  		 */
eb66ae03082960 Linus Torvalds    2018-10-12  257  		if (pte_present(pte))
5d1904204c9959 Aaron Lu          2016-11-10  258  			force_flush = true;
82a616d0f33b77 David Hildenbrand 2024-03-27  259  		pte = move_pte(pte, old_addr, new_addr);
6dec97dc92946e Cyrill Gorcunov   2013-08-27  260  		pte = move_soft_dirty_pte(pte);
0cef0bb836e3cf Ryan Roberts      2025-01-07  261  
0cef0bb836e3cf Ryan Roberts      2025-01-07  262  		if (need_clear_uffd_wp && pte_marker_uffd_wp(pte))
0cef0bb836e3cf Ryan Roberts      2025-01-07  263  			pte_clear(mm, new_addr, new_pte);
0cef0bb836e3cf Ryan Roberts      2025-01-07  264  		else {
0cef0bb836e3cf Ryan Roberts      2025-01-07  265  			if (need_clear_uffd_wp) {
0cef0bb836e3cf Ryan Roberts      2025-01-07  266  				if (pte_present(pte))
0cef0bb836e3cf Ryan Roberts      2025-01-07  267  					pte = pte_clear_uffd_wp(pte);
0cef0bb836e3cf Ryan Roberts      2025-01-07  268  				else if (is_swap_pte(pte))
0cef0bb836e3cf Ryan Roberts      2025-01-07  269  					pte = pte_swp_clear_uffd_wp(pte);
0cef0bb836e3cf Ryan Roberts      2025-01-07  270  			}
6dec97dc92946e Cyrill Gorcunov   2013-08-27  271  			set_pte_at(mm, new_addr, new_pte, pte);
^1da177e4c3f41 Linus Torvalds    2005-04-16  272  		}
0cef0bb836e3cf Ryan Roberts      2025-01-07  273  	}
7be7a546994f12 Hugh Dickins      2005-10-29  274  
6606c3e0da5360 Zachary Amsden    2006-09-30  275  	arch_leave_lazy_mmu_mode();
eb66ae03082960 Linus Torvalds    2018-10-12  276  	if (force_flush)
eb66ae03082960 Linus Torvalds    2018-10-12  277  		flush_tlb_range(vma, old_end - len, old_end);
4c21e2f2441dc5 Hugh Dickins      2005-10-29  278  	if (new_ptl != old_ptl)
4c21e2f2441dc5 Hugh Dickins      2005-10-29  279  		spin_unlock(new_ptl);
ece0e2b6406a99 Peter Zijlstra    2010-10-26  280  	pte_unmap(new_pte - 1);
c74df32c724a16 Hugh Dickins      2005-10-29  281  	pte_unmap_unlock(old_pte - 1, old_ptl);
a5be621ee2925b Hugh Dickins      2023-06-08  282  out:
664dc4da2694fa Lorenzo Stoakes   2025-03-10  283  	if (pmc->need_rmap_locks)
1d069b7dd56728 Hugh Dickins      2016-05-19  284  		drop_rmap_locks(vma);
a5be621ee2925b Hugh Dickins      2023-06-08  285  	return err;
^1da177e4c3f41 Linus Torvalds    2005-04-16  286  }
^1da177e4c3f41 Linus Torvalds    2005-04-16  287  

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

      parent reply	other threads:[~2025-05-27 17:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-27 13:23 [RFC PATCH v2 0/2] Fix uprobe anon page be overwritten during mremap Pu Lehui
2025-05-27 13:23 ` [RFC PATCH v2 1/2] mm/mremap: Fix uprobe anon page be overwritten when expanding vma " Pu Lehui
2025-05-27 13:34   ` Lorenzo Stoakes
2025-05-27 15:17     ` Oleg Nesterov
2025-05-27 15:27       ` Lorenzo Stoakes
2025-05-27 15:29     ` Lorenzo Stoakes
2025-05-27 16:29     ` Pu Lehui
2025-05-27 14:23   ` Oleg Nesterov
2025-05-27 16:32     ` Pu Lehui
2025-05-27 16:37       ` Lorenzo Stoakes
2025-05-27 16:52         ` Pu Lehui
2025-05-27 17:20       ` Oleg Nesterov
2025-05-29 15:09         ` Pu Lehui
2025-05-29 15:12           ` Lorenzo Stoakes
2025-05-27 15:30   ` Oleg Nesterov
2025-05-27 15:33     ` Lorenzo Stoakes
2025-05-27 15:52       ` Oleg Nesterov
2025-05-27 16:41       ` Pu Lehui
2025-05-27 16:35     ` Pu Lehui
2025-05-27 13:23 ` [RFC PATCH v2 2/2] mm/mremap: Expose abnormal new_pte during move_ptes Pu Lehui
2025-05-27 14:24   ` Oleg Nesterov
2025-05-27 17:57   ` kernel test robot [this message]

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=202505280152.hvGSNcAt-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=pulehui@huaweicloud.com \
    /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.