From: kernel test robot <lkp@intel.com>
To: Shivank Garg <shivankg@amd.com>
Cc: oe-kbuild-all@lists.linux.dev,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Baolin Wang <baolin.wang@linux.alibaba.com>
Subject: [akpm-mm:mm-unstable 36/67] mm/khugepaged.c:2337:7: error: implicit declaration of function 'folio_expected_ref_count'; did you mean 'folio_ref_count'?
Date: Wed, 28 May 2025 20:16:31 +0800 [thread overview]
Message-ID: <202505282015.F0fVmLmH-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
head: 52ce652e7ab0f015b51fee11b2862507b2c0c25d
commit: 3bdddbba5f02f6d97283acb18e2a6e079324fe4b [36/67] mm/khugepaged: fix race with folio split/free using temporary reference
config: arm64-randconfig-002-20250528 (https://download.01.org/0day-ci/archive/20250528/202505282015.F0fVmLmH-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 7.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250528/202505282015.F0fVmLmH-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/202505282015.F0fVmLmH-lkp@intel.com/
Note: the akpm-mm/mm-unstable HEAD 52ce652e7ab0f015b51fee11b2862507b2c0c25d builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
mm/khugepaged.c: In function 'hpage_collapse_scan_file':
>> mm/khugepaged.c:2337:7: error: implicit declaration of function 'folio_expected_ref_count'; did you mean 'folio_ref_count'? [-Werror=implicit-function-declaration]
if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) {
^~~~~~~~~~~~~~~~~~~~~~~~
folio_ref_count
cc1: some warnings being treated as errors
vim +2337 mm/khugepaged.c
2266
2267 static int hpage_collapse_scan_file(struct mm_struct *mm, unsigned long addr,
2268 struct file *file, pgoff_t start,
2269 struct collapse_control *cc)
2270 {
2271 struct folio *folio = NULL;
2272 struct address_space *mapping = file->f_mapping;
2273 XA_STATE(xas, &mapping->i_pages, start);
2274 int present, swap;
2275 int node = NUMA_NO_NODE;
2276 int result = SCAN_SUCCEED;
2277
2278 present = 0;
2279 swap = 0;
2280 memset(cc->node_load, 0, sizeof(cc->node_load));
2281 nodes_clear(cc->alloc_nmask);
2282 rcu_read_lock();
2283 xas_for_each(&xas, folio, start + HPAGE_PMD_NR - 1) {
2284 if (xas_retry(&xas, folio))
2285 continue;
2286
2287 if (xa_is_value(folio)) {
2288 swap += 1 << xas_get_order(&xas);
2289 if (cc->is_khugepaged &&
2290 swap > khugepaged_max_ptes_swap) {
2291 result = SCAN_EXCEED_SWAP_PTE;
2292 count_vm_event(THP_SCAN_EXCEED_SWAP_PTE);
2293 break;
2294 }
2295 continue;
2296 }
2297
2298 if (!folio_try_get(folio)) {
2299 xas_reset(&xas);
2300 continue;
2301 }
2302
2303 if (unlikely(folio != xas_reload(&xas))) {
2304 folio_put(folio);
2305 xas_reset(&xas);
2306 continue;
2307 }
2308
2309 if (folio_order(folio) == HPAGE_PMD_ORDER &&
2310 folio->index == start) {
2311 /* Maybe PMD-mapped */
2312 result = SCAN_PTE_MAPPED_HUGEPAGE;
2313 /*
2314 * For SCAN_PTE_MAPPED_HUGEPAGE, further processing
2315 * by the caller won't touch the page cache, and so
2316 * it's safe to skip LRU and refcount checks before
2317 * returning.
2318 */
2319 folio_put(folio);
2320 break;
2321 }
2322
2323 node = folio_nid(folio);
2324 if (hpage_collapse_scan_abort(node, cc)) {
2325 result = SCAN_SCAN_ABORT;
2326 folio_put(folio);
2327 break;
2328 }
2329 cc->node_load[node]++;
2330
2331 if (!folio_test_lru(folio)) {
2332 result = SCAN_PAGE_LRU;
2333 folio_put(folio);
2334 break;
2335 }
2336
> 2337 if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) {
2338 result = SCAN_PAGE_COUNT;
2339 folio_put(folio);
2340 break;
2341 }
2342
2343 /*
2344 * We probably should check if the folio is referenced
2345 * here, but nobody would transfer pte_young() to
2346 * folio_test_referenced() for us. And rmap walk here
2347 * is just too costly...
2348 */
2349
2350 present += folio_nr_pages(folio);
2351 folio_put(folio);
2352
2353 if (need_resched()) {
2354 xas_pause(&xas);
2355 cond_resched_rcu();
2356 }
2357 }
2358 rcu_read_unlock();
2359
2360 if (result == SCAN_SUCCEED) {
2361 if (cc->is_khugepaged &&
2362 present < HPAGE_PMD_NR - khugepaged_max_ptes_none) {
2363 result = SCAN_EXCEED_NONE_PTE;
2364 count_vm_event(THP_SCAN_EXCEED_NONE_PTE);
2365 } else {
2366 result = collapse_file(mm, addr, file, start, cc);
2367 }
2368 }
2369
2370 trace_mm_khugepaged_scan_file(mm, folio, file, present, swap, result);
2371 return result;
2372 }
2373 #else
2374 static int hpage_collapse_scan_file(struct mm_struct *mm, unsigned long addr,
2375 struct file *file, pgoff_t start,
2376 struct collapse_control *cc)
2377 {
2378 BUILD_BUG();
2379 }
2380 #endif
2381
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next reply other threads:[~2025-05-28 12:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 12:16 kernel test robot [this message]
2025-05-28 12:34 ` [akpm-mm:mm-unstable 36/67] mm/khugepaged.c:2337:7: error: implicit declaration of function 'folio_expected_ref_count'; did you mean 'folio_ref_count'? Shivank Garg
2025-05-28 18:44 ` Andrew Morton
2025-05-29 3:46 ` Shivank Garg
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=202505282015.F0fVmLmH-lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=linux-mm@kvack.org \
--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 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.