Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Shivank Garg <shivankg@amd.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	0day robot <lkp@intel.com>
Subject: mm/rmap.c:2522:7: error: call to undeclared function 'huge_pte_dirty'; ISO C99 and later do not support implicit function declarations
Date: Tue, 14 Jul 2026 14:02:45 +0200	[thread overview]
Message-ID: <202607141439.zBAJhYoU-lkp@intel.com> (raw)

tree:   https://github.com/intel-lab-lkp/linux/commits/Shivank-Garg/mm-rmap-Add-batched-version-of-folio_try_share_anon_rmap_pte/20260712-154356
head:   f8b98e18fdb1e935473b34c81c54112651ac2e3d
commit: b1567f49975671161a4df476e9068bda9c3df9ae mm/rmap: split try_to_migrate_hugetlb_one() out of try_to_migrate_one()
date:   2 days ago
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260714/202607141439.zBAJhYoU-lkp@intel.com/config)
compiler: clang version 22.1.8 (https://github.com/llvm/llvm-project ca7933e47d3a3451d81e72ac174dcb5aa28b59d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260714/202607141439.zBAJhYoU-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/202607141439.zBAJhYoU-lkp@intel.com/

All errors (new ones prefixed by >>):

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


vim +/huge_pte_dirty +2522 mm/rmap.c

  2443	
  2444	/*
  2445	 * Replace the hugetlb page table mapping for folio with migration entries.
  2446	 *
  2447	 * @arg: enum ttu_flags will be passed to this argument.
  2448	 */
  2449	static bool try_to_migrate_hugetlb_one(struct folio *folio,
  2450			struct vm_area_struct *vma, unsigned long address, void *arg)
  2451	{
  2452		const unsigned long hsz = huge_page_size(hstate_vma(vma));
  2453		DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, address, 0);
  2454		enum ttu_flags flags = (enum ttu_flags)(long)arg;
  2455		bool anon_exclusive, writable, ret = true;
  2456		bool anon = folio_test_anon(folio);
  2457		struct mm_struct *mm = vma->vm_mm;
  2458		struct mmu_notifier_range range;
  2459		unsigned long pfn;
  2460		struct page *page;
  2461		pte_t pteval;
  2462	
  2463		range.end = vma_address_end(&pvmw);
  2464		mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma->vm_mm,
  2465					address, range.end);
  2466		/* If sharing is possible, start and end will be adjusted accordingly. */
  2467		adjust_range_if_pmd_sharing_possible(vma, &range.start, &range.end);
  2468		mmu_notifier_invalidate_range_start(&range);
  2469	
  2470		if (page_vma_mapped_walk(&pvmw)) {
  2471			address = pvmw.address;
  2472			pteval = huge_ptep_get(mm, address, pvmw.pte);
  2473			if (likely(pte_present(pteval)))
  2474				pfn = pte_pfn(pteval);
  2475			else
  2476				pfn = softleaf_to_pfn(softleaf_from_pte(pteval));
  2477	
  2478			page = folio_page(folio, pfn - folio_pfn(folio));
  2479			anon_exclusive = anon && PageAnonExclusive(page);
  2480	
  2481			/*
  2482			 * huge_pmd_unshare may unmap an entire PMD page. There is no
  2483			 * way of knowing exactly which PMDs may be cached for this mm,
  2484			 * so we must flush them all. start/end were already adjusted
  2485			 * above to cover this range.
  2486			 */
  2487			flush_cache_range(vma, range.start, range.end);
  2488	
  2489			/*
  2490			 * To call huge_pmd_unshare, i_mmap_rwsem must be held in write
  2491			 * mode. Caller needs to explicitly do this outside rmap
  2492			 * routines. We also must hold hugetlb vma_lock in write mode.
  2493			 * Lock order dictates acquiring vma_lock BEFORE i_mmap_rwsem.
  2494			 * We can only try lock here and fail if unsuccessful.
  2495			 */
  2496			if (!anon) {
  2497				struct mmu_gather tlb;
  2498	
  2499				VM_WARN_ON_ONCE(!(flags & TTU_RMAP_LOCKED));
  2500				if (!hugetlb_vma_trylock_write(vma)) {
  2501					ret = false;
  2502					goto walk_done;
  2503				}
  2504	
  2505				tlb_gather_mmu_vma(&tlb, vma);
  2506				if (huge_pmd_unshare(&tlb, vma, address, pvmw.pte)) {
  2507					hugetlb_vma_unlock_write(vma);
  2508					huge_pmd_unshare_flush(&tlb, vma);
  2509					tlb_finish_mmu(&tlb);
  2510					/*
  2511					 * The PMD table was unmapped,
  2512					 * consequently unmapping the folio.
  2513					 */
  2514					goto walk_done;
  2515				}
  2516				hugetlb_vma_unlock_write(vma);
  2517				tlb_finish_mmu(&tlb);
  2518			}
  2519	
  2520			/* Nuke the hugetlb page table entry */
  2521			pteval = huge_ptep_clear_flush(vma, address, pvmw.pte);
> 2522			if (huge_pte_dirty(pteval))
  2523				folio_mark_dirty(folio);
  2524			writable = pte_write(pteval);
  2525	
  2526			VM_WARN_ON_FOLIO(writable && anon && !anon_exclusive, folio);
  2527	
  2528			if (PageHWPoison(page)) {
  2529				pteval = swp_entry_to_pte(make_hwpoison_entry(page));
  2530				hugetlb_count_sub(folio_nr_pages(folio), mm);
  2531				set_huge_pte_at(mm, address, pvmw.pte, pteval, hsz);
  2532			} else if (likely(pte_present(pteval)) && pte_unused(pteval) &&
  2533				   !userfaultfd_armed(vma)) {
  2534				/*
  2535				 * The guest indicated that the page content is of no
  2536				 * interest anymore. Simply discard the pte, vmscan
  2537				 * will take care of the rest.
  2538				 */
  2539				dec_mm_counter(mm, mm_counter(folio));
  2540			} else {
  2541				pte_t swp_pte;
  2542	
  2543				/*
  2544				 * arch_unmap_one() is expected to be a NOP on
  2545				 * architectures where we could have PFN swap PTEs,
  2546				 * so we'll not check/care.
  2547				 */
  2548				if (arch_unmap_one(mm, vma, address, pteval) < 0) {
  2549					set_huge_pte_at(mm, address, pvmw.pte,
  2550							pteval, hsz);
  2551					ret = false;
  2552					goto walk_done;
  2553				}
  2554	
  2555				/* See folio_try_share_anon_rmap_pte(): clear PTE first. */
  2556				if (anon_exclusive &&
  2557				    hugetlb_try_share_anon_rmap(folio)) {
  2558					set_huge_pte_at(mm, address, pvmw.pte,
  2559							pteval, hsz);
  2560					ret = false;
  2561					goto walk_done;
  2562				}
  2563	
  2564				/*
  2565				 * Store the pfn of the page in a special migration
  2566				 * pte. do_swap_page() will wait until the migration
  2567				 * pte is removed and then restart fault handling.
  2568				 */
  2569				swp_pte = make_migration_swp_pte(page, pteval,
  2570								 writable, anon_exclusive);
  2571				set_huge_pte_at(mm, address, pvmw.pte, swp_pte, hsz);
  2572				trace_set_migration_pte(address, pte_val(swp_pte),
  2573							folio_order(folio));
  2574			}
  2575	
  2576			hugetlb_remove_rmap(folio);
  2577			if (vma->vm_flags & VM_LOCKED)
  2578				mlock_drain_local();
  2579			folio_put(folio);
  2580	walk_done:
  2581			page_vma_mapped_walk_done(&pvmw);
  2582		}
  2583	
  2584		mmu_notifier_invalidate_range_end(&range);
  2585	
  2586		return ret;
  2587	}
  2588	

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

                 reply	other threads:[~2026-07-14 12:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=202607141439.zBAJhYoU-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=shivankg@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox